From owner-freebsd-security@FreeBSD.ORG Sat Dec 27 00:21:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11AD0ECF for ; Sat, 27 Dec 2014 00:21:22 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96986677C8 for ; Sat, 27 Dec 2014 00:21:21 +0000 (UTC) X-SubmittedBy: /C=CZ/O=Univerzita+20Karlova+20v+20Praze/CN=Dan+20Lukes/unstructuredName=100000045929 issued by /C=NL/O=TERENA/CN=TERENA+20Personal+20CA auth type TLS.MFF Received: from kgw.obluda.cz ([194.108.204.138]) (authenticated) by smtp1.ms.mff.cuni.cz (8.14.9/8.14.9) with ESMTP id sBR06KBI084265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Sat, 27 Dec 2014 01:21:18 +0100 (CET) (envelope-from dan@obluda.cz) Message-ID: <549DF7FC.10109@obluda.cz> Date: Sat, 27 Dec 2014 01:06:20 +0100 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:31.ntp References: <20141223233310.098C54BB6@nine.des.no> <549C4D71.6030704@bluerosetech.com> <25260C1A-8230-47BD-9FAF-585D2B560303@FreeBSD.org> <549DE2B4.4080806@bluerosetech.com> In-Reply-To: <549DE2B4.4080806@bluerosetech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 00:21:22 -0000 On 12/26/14 23:35, Darren Pilgrim: >>>> IV. Workaround >>>> No workaround is available, >> We talk explicitly about the base system, not about ports. We never >> mentioned them and I do not see a reason to start doing so. > I don't understand why you wouldn't. Hm ... We can turn off vulnerable service. We can replace vulnerable software by another, non vulnerable. We can leave vulnerable service running, but block access to it. Security advisory is advisory. An administrator should make own decisions based on it. I'm pretty sure the system administrators are recognizing those obvious things despite not mentioned explicitly. It require basic skills only. I disagree that obvious things should be enumerated in SA. The SA should be short and readable. In advance, Security Officer should not recommend other software as secure replacement unless he consider it secure. Such analysis take a lot of time and it will cause unacceptable delay of SA. Just my $0.02 Dan