Date: Wed, 26 Mar 2014 07:08:57 +0200 From: Kimmo Paasiala <kpaasial@icloud.com> To: Olafur Gudmundsson <ogud@ogud.com> Cc: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? (Gary Palmer) Message-ID: <FD8D10B1-9A78-4732-B379-718048D82FBF@icloud.com> In-Reply-To: <EAD9B42E-3A77-4254-B9C6-4B0FAFE4F246@ogud.com> References: <mailman.89.1395748802.54679.freebsd-security@freebsd.org> <EAD9B42E-3A77-4254-B9C6-4B0FAFE4F246@ogud.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_96A045FA-42E4-47B6-AD00-2F01A4CE7769 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25.3.2014, at 15.48, Olafur Gudmundsson <ogud@ogud.com> wrote: >=20 > On Mar 25, 2014, at 8:00 AM, freebsd-security-request@freebsd.org = wrote: >=20 >>=20 >> Message: 1 >> Date: Mon, 24 Mar 2014 11:02:08 -0400 >> From: Gary Palmer <gpalmer@freebsd.org> >> To: Brett Glass <brett@lariat.org> >> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, >> Remko Lodder <remko@freebsd.org>, "Ronald F. Guilmette" >> <rfg@tristatelogic.com> >> 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 >=20 > 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 >=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 >=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 >=20 > So while it is possible to move NTP servers off port 123 I do not = think it is worth the effort.=20 >=20 > Olafur >=20 >=20 I believe Gary was talking about changing the control/status port and = not the actual service port (UDP 123). That should be doable without = breaking compatibility with existing NTP tools. -Kimmo --Apple-Mail=_96A045FA-42E4-47B6-AD00-2F01A4CE7769 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTMmDuAAoJEFvLZC0FWRVpqYgIAKDVzHYimNLQRz5vUfbKphM/ M8PAU6gsc5d30O7td6oRqty5Z3nRT8byHCnEIJrDlDLUBK5YQ+GJdlnj06Kpysnb Tf/CbB5IcCdszhextMp2ahS4JtDJ7ubHbGq6CXp34dJXHcueLjpqAUhIOVya7r9F bmdlHGsDnmi59dIz3TJbeWbHmnkDyLWsdFFeoGSl9TRKtcTDlCLHLI7bekd5CEah /kx/iN756g7F3sEqPUXk+SQSfYeOwhp4Urhmipa6eqSO0m0R16VBW8OYFYM84n0N M54WhAz3PYXlZHYe086h/HZecwdyAVh6O23Km9Mm89LPzqL+BXC8pEQKJvBv2S0= =P4c/ -----END PGP SIGNATURE----- --Apple-Mail=_96A045FA-42E4-47B6-AD00-2F01A4CE7769--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FD8D10B1-9A78-4732-B379-718048D82FBF>