From owner-freebsd-security@FreeBSD.ORG Mon Mar 24 15:51:57 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D152CA94; Mon, 24 Mar 2014 15:51:57 +0000 (UTC) Received: from mail.in-addr.com (noop.in-addr.com [208.58.23.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A14BC69C; Mon, 24 Mar 2014 15:51:57 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WS6O8-0002rK-Nw; Mon, 24 Mar 2014 11:02:08 -0400 Date: Mon, 24 Mar 2014 11:02:08 -0400 From: Gary Palmer To: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? Message-ID: <20140324150208.GA5238@in-addr.com> References: <51381.1395429637@server1.tristatelogic.com> <8F3083F1-3A20-4FEC-9969-F9968D87569E@FreeBSD.org> <201403220013.SAA15675@mail.lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201403220013.SAA15675@mail.lariat.net> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false Cc: "freebsd-security@freebsd.org" , Remko Lodder , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:51:57 -0000 On Fri, Mar 21, 2014 at 06:13:10PM -0600, Brett Glass wrote: > At 03:28 PM 3/21/2014, Remko Lodder wrote: > > >Ofcourse the software should be well protected as well, and secteam@ did his > >best to offer the best solution possible. Though as mentioned by Brett for > >example we just cannot force the update of ntpd.conf on user machines because > >every admin could have legitimate reasons for having a configuration in place > >they decided to have. It's risky to change those things and especially enforce > >them on running machines. Most of his ideas were in the advisory already > >except for the 'disable monitor' part, which might be reason to discuss > >whether that makes sense or not. > > I've suggested one other thing, and still think it would be a good idea to > thwart attacks: that we compile ntpd to source outgoing queries from randomly > selected ephemeral UDP ports rather than UDP port 123. (This was, > in fact, done > in earlier releases of FreeBSD and I'm unsure why it was changed.) This makes > stateful firewalling less necessary and improves its performance if it is done. Could you please explain how randomising the source port of NTP queries would thwart NTP monitor amplification attacks? The attack works because the NTP control port on the server is always UDP/123, and I don't see how changing the source port would fix that. Unless I'm missing something, you'd need to change the port the daemon accepts queries on, not the port it sources outbound queries on. Thanks, Gary