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

Danny Mayer mayer at ntp.org
Wed Nov 4 04:40:26 UTC 2015

On 11/3/2015 4:41 PM, Charles Swiger wrote:
> On Nov 3, 2015, at 11:45 AM, Danny Mayer <mayer at ntp.org> wrote:
>> On 11/3/2015 3:51 AM, Miroslav Lichvar wrote:
>>> On Mon, Nov 02, 2015 at 04:01:13PM -0500, Danny Mayer wrote:
>>>> On 11/2/2015 6:45 AM, Miroslav Lichvar wrote:
>>> This allows an off-path attacker to set the
>>> client's minpoll to its current poll and prevent it from using a
>>> shorter poll later when the temperature changes rapidly for instance.
>> Not any more. This now fails as it needs an outstanding valid origin
>> timestamp so off-path attackers don't have that option.
> If the attacker can observe legitimate requests it has that data, but
> mitigating against "off-path" attackers is certainly worthwhile as well.
No. An attacker can observe the legitimate requests but cannot use the
origin timestamp because it will already have been used by the server's
response and reset to zero in the association on the client.

>>> If the client was fixed to not shorten its polling interval with a KoD
>>> RATE reply, the server could always set the KoD poll to the rate
>>> limiting interval and prevent this attack.
>> It won't prevent it since the attacker can continue to bombard the
>> server with packets forcing it to issue KoD RATE packets every time.
> An attacker with sufficient bandwidth can flood your incoming pipe, but
> it seems desirable to switch from:
> - replying normally to source IP
> - replying with a KoD RATE reply, if source is sending requests too fast
> - replying with KoD DENY, if the source continues sending requests
> - simply dropping future requests from that source for $LONGTIME ~= 1 day.
> This does the right thing for clients which want time but are being naughty
> and querying too fast, as well as for full DDoS attacks where the source IP
> is forged and might even be the intended target.

I'm not sure it's workable. I'd have to think about that.
>>> Also, it might be a good idea to remove the DENY and RSTR codes from
>>> the spec, or at least require authentication for them. They are too
>>> powerful.
>> I disagree. A configured server might send out a DENY KoD once and after
>> that ignore all packets from that IP address. The DENY is intended to
>> tell the client to go away and it doesn't matter if this is from an
>> off-path attacker or is a valid packet from that address. The fact that
>> it was a real valid request doesn't mean that the server should allow it.
> Yes.
>>>> 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.
>>> I'm not sure I follow here.
>>> When a client packet hits the limit on a server with enabled rate
>>> limiting, the server can do one of the following:
>>>  A) ignore the packet
>>>  B) reply with normal packet, which has valid timestamps
>>>  C) reply with KoD RATE packet, which doesn't have valid timestamps
>>> Currently, if restrict kod is disabled, ntpd always does A. When
>>> restrict kod is enabled, it selects between A and C, depending on how
>>> long it was since last C. B is never used, which allows the attack we
>>> are trying to prevent.
>>> With the suggested change, ntpd would select randomly between A and B
>>> when restrict kod is disabled, and select randomly between A, B and C
>>> when restrict kod is enabled. The A/(B+C) and B/C ratios could be
>>> fixed, or they could be configurable.
>> If the target is under attack then the server doesn't know if the
>> request is valid or not so responding with B is just as likely to be
>> lost as it was more likely to be a forged packet in the first place.
> I think ntpd should move from B to C to A, if the traffic rate continues
> to exceed reasonable polling frequency.
The real client needs B to be useful but how do you know it's a
legitimate client request?


More information about the hackers mailing list