NTP security hole CVE-2013-5211? (Gary Palmer)
Kimmo Paasiala
kpaasial at icloud.com
Wed Mar 26 06:11:41 UTC 2014
On 25.3.2014, at 15.48, Olafur Gudmundsson <ogud at ogud.com> wrote:
>
> On Mar 25, 2014, at 8:00 AM, freebsd-security-request at freebsd.org wrote:
>
>>
>> Message: 1
>> Date: Mon, 24 Mar 2014 11:02:08 -0400
>> From: Gary Palmer <gpalmer at freebsd.org>
>> To: Brett Glass <brett at lariat.org>
>> Cc: "freebsd-security at freebsd.org" <freebsd-security at freebsd.org>,
>> Remko Lodder <remko at freebsd.org>, "Ronald F. Guilmette"
>> <rfg at tristatelogic.com>
>> Subject: Re: NTP security hole CVE-2013-5211?
>> Message-ID: <20140324150208.GA5238 at in-addr.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> 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
>
> There are three problems
> 0. NTP can be tricked to give out big answer to forged addresses.
> 1. Some NTP servers listen on port 123 all address even when only expecting to providing service on
> "internal addresses",
> 2. NTP servers are easily discoverable due to the listening on fixed port.
>
> Moving the servers of port 123 will make the search for servers harder but intrusion detection systems
> will need to be modified to expect NTP traffic on any port.
>
> IF and ONLY if people are willing to change how NTP servers are discovered in DNS then servers
> can listen on any port.
> 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
> there still has to be "temporarily" backwards hack to allow old software to find the service.
> (In the mail world MX (SRV equivalent) use is not universal after over 25 years).
>
> So while it is possible to move NTP servers off port 123 I do not think it is worth the effort.
>
> Olafur
>
>
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140326/aa344c28/attachment.sig>
More information about the freebsd-security
mailing list