From owner-freebsd-security@FreeBSD.ORG Tue Mar 25 13:56:41 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 B9DBBB9A for ; Tue, 25 Mar 2014 13:56:41 +0000 (UTC) Received: from smtp118.ord1c.emailsrvr.com (smtp118.ord1c.emailsrvr.com [108.166.43.118]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87A22E49 for ; Tue, 25 Mar 2014 13:56:41 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id BCD3D2F009B for ; Tue, 25 Mar 2014 09:48:14 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 464DC1B95E7 for ; Tue, 25 Mar 2014 09:48:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: NTP security hole CVE-2013-5211? (Gary Palmer) From: Olafur Gudmundsson In-Reply-To: Date: Tue, 25 Mar 2014 09:48:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1510) 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: Tue, 25 Mar 2014 13:56:41 -0000 On Mar 25, 2014, at 8:00 AM, freebsd-security-request@freebsd.org wrote: >=20 > Message: 1 > Date: Mon, 24 Mar 2014 11:02:08 -0400 > From: Gary Palmer > To: Brett Glass > Cc: "freebsd-security@freebsd.org" , > Remko Lodder , "Ronald F. Guilmette" > > Subject: Re: NTP security hole CVE-2013-5211? > Message-ID: <20140324150208.GA5238@in-addr.com> > Content-Type: text/plain; charset=3Dus-ascii >=20 > On Fri, Mar 21, 2014 at 06:13:10PM -0600, Brett Glass wrote: >> At 03:28 PM 3/21/2014, Remko Lodder wrote: >>=20 >>> 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. >>=20 >> 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,=20 >> 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. >=20 >=20 > 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. >=20 > Thanks, >=20 > Gary There are three problems=20 0. NTP can be tricked to give out big answer to forged addresses.=20 1. Some NTP servers listen on port 123 all address even when only = expecting to providing service on=20 "internal addresses", 2. NTP servers are easily discoverable due to the listening on fixed = port. =20 Moving the servers of port 123 will make the search for servers harder = but intrusion detection systems=20 will need to be modified to expect NTP traffic on any port.=20 IF and ONLY if people are willing to change how NTP servers are = discovered in DNS then servers can listen on any port.=20 Instead of loping up "A/AAAA" record for a name, the service discovery = should look up SRV record as that includes port number on each server. Even if everyone agrees to = make this change=20 there still has to be "temporarily" backwards hack to allow old software = to find the service.=20 (In the mail world MX (SRV equivalent) use is not universal after over = 25 years).=20 So while it is possible to move NTP servers off port 123 I do not think = it is worth the effort.=20 Olafur