[ntp:hackers] [Pool] NTP CVE patches?

Danny Mayer mayer at ntp.org
Mon Nov 2 21:01:13 UTC 2015

On 11/2/2015 6:45 AM, Miroslav Lichvar wrote:
> On Mon, Oct 26, 2015 at 08:01:36PM +0000, Harlan Stenn wrote:
>> Miroslav Lichvar writes:
>>> If the rate limiting as currently implemented is vulnerable, I think
>>> it should be either removed or fixed. It seems in DNS they were able
>>> to fix it.
>> Yes, and I'm happy to fix this sooner and it will require IETF working
>> group changes to the v4 spec.
> Which part of the RFC will need to be updated? I don't see anything
> relevant to the rate limiting or KoD on servers there. From the open
> source NTP implementations, it seems only ntpd implements the rate
> limiting and its description wasn't included in the RFC.

Rate limiting is described in RFC5905 Section 7.4.b. How it is to be
implemented is left to the implementation.

> The part on handling KoD packets on clients could definitely be
> improved though.

In what way? We are looking at limiting the rate change implemented to
not exceed certain limits but we still have to decide what a maximum
limit would be.

>>>>> I think it also creates a new problem that an attacker could spam the
>>>>> client's syslog with these messages and fill the disk. Harlan, could
>>>>> you please consider adding a rate limit for the message to prevent
>>>>> that?
>> Let's cut thru this.  What do you propose as a solution?
> Remove that log message or add a rate limit for it, e.g. allow only
> one message per minute and the source. The fix for CVE-2015-7850 that
> was included in 4.2.8p4 is a form of rate limiting. If it was extended
> to allow multiple instances and check also time since last message,
> maybe it could be used in this case too.
>>>> If the client is the victim of a DoS attack from forged sources, that's
>>>> something to report to the server operator and network operators.
>>> Realistically, what they can do about it?
>> Report it to the server operators and network operators.  From there,
>> who knows?
> They can preach about BCP 38 and hope someday the internet will be
> "fixed". That's probably all they can do.
>>> The proposal is to reply only to a fraction of the requests (chosen
>>> randomly) if restrict limited is enabled and the limit is reached.
>>> If also restrict kod is enabled, the fraction of the replies (chosen
>>> randomly) would be KoD RATE packets, but most of the replies the
>>> client would get would still be useful for synchronization.
>> Yes, and we'll be doing this (patches welcome) and it will require an
>> update to the RFC.
> Are you still interested in the patch? I can prepare one if NTF hasn't
> assigned it to someone yet.

I don't see how you can respond to some of these packets and others with
KoD RATE packets. There's a reason for these RATE KoD's and that hasn't
gone away. The RFC cannot be updated without adding some sort of
signalling since now you will have conflicting possible responses and
you will have no way otherwise of knowing which is which.

>>> There would be a change in the case of abusive clients though.
>>> Currently, if a client is always sending its requests too frequently
>>> and it doesn't fall off the monitoring list, it will get only KoD
>>> replies, which don't have the server's time. I think the intention was
>>> to let such clients drift away from true time, the user notice the
>>> clock is wrong, investigate the problem and get the implementation
>>> fixed. I'm wondering if that ever happened.
>> What part are you wondering about?  Not many folks seem to have used
>> KoD, as best as I can tell.
> The part about not sending any useful timestamps to the client so it
> drifts away and the user getting the implementation fixed.

That's as defined in Section 7.4 of the RFC. You can't have a KoD AND a
valid set of timestamps.

>>>> The best idea I've had is that if a client is getting unexpected replies
>>>> from a server that it send a query packet before the server might start
>>>> to send KoD responses, as there's a decent chance that the server might
>>>> soon stop responding to packets claiming to be from the client/target IP.
>>> I'm not sure how would that help. When the client gets a reply to a
>>> spoofed request, it may already be blocked and it won't get any
>>> further replies to its own requests. Also, couldn't be this behavior
>>> (sending new request when a bad reply is received) exploited for some
>>> other attacks?
>> Blocked as the result of a single packet?

Multiple packets.

> The attacker can send a burst of requests to the server. By the time
> the client gets a reply to the first packet, it may already be
> blocked.


>> If the client is configured with an inadequate number of servers then
>> what can we do and how far should we go to "help" them?
> I don't think number of servers really matters here as the attacker
> can send spoofed packets to all servers the client is or may be using.
> I think the fix is, as you seem to agree, to make the attack pointless
> by not completely starving the clients when they appear to be sending
> too many requests.

That's where using the pool helps since you can get a new set of servers
before the attacker can start sending spoof packets to a new set of servers.


More information about the hackers mailing list