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

Danny Mayer mayer at ntp.org
Thu Nov 5 21:40:13 UTC 2015


On 11/4/2015 3:15 AM, Miroslav Lichvar wrote:
> On Tue, Nov 03, 2015 at 02:45:25PM -0500, Danny Mayer wrote:
>> On 11/3/2015 3:51 AM, Miroslav Lichvar wrote:
>>> Right, it seems there is nothing in the RFC that would need to be
>>> updated in order to allow implementation of the new approach discussed
>>> in this thread.
>>
>> You need to be careful here. The current implementation needs to taken
>> into account when making any changes. Interoperability is key especially
>> with long-lived usage of existing code. That's what I am worrying about.
> 
> Yes, that's why we need to test the new approach first on a public
> server and see if there isn't an implementation that would break
> horribly with it. But this has nothing to do with the RFC. It doesn't
> describe or require the current ntpd rate limiting implementation and
> it doesn't prevent implementation of the suggested approach.
> 

That's not quite true due to interoperability issues. You do have to do
extensive testing but we also need the resources to do so.

>>> It would be nice if ntpd as a client didn't shorten its polling
>>> interval when the received KoD RATE packet has poll smaller than the
>>> current host poll. Currently, ntpd as a server sets the poll value in
>>> KoD packets to the maximum of the client's poll and the configured
>>> rate limiting interval.
>>
>> Actually it's the maximum of the received packet's poll value and the
>> min poll of the server:
>> xpkt.ppoll = max(rpkt->ppoll, ntp_minpoll);
>>
>> The server doesn't know the clients poll settings.
> 
> It does know the current client's polling interval, that is the poll
> value in the packet. When the client is configured with minpoll 6
> maxpoll 10 and is currently polling the server at poll 10, the
> client packet will have poll 10 and the KoD poll value will be maximum
> of ntp_minpoll and 10, i.e. 10 with default ntp_minpoll of 3.

Actualy it doesn't. It only knows about the poll setting given in the
received packet. That was the motivation factor for the vunerability
report because the attacker could set it to anything.

> 
> When the attacker triggers the rate limit on the server with spoofed
> packets and then the server replies to a genuine client request
> with KoD RATE packet having poll 10, it will set the client's minpoll
> to 10. It won't longer be able to switch to 6 when needed, even though
> the server requires just that the poll is >= 3 and 6 would be
> perfectly fine.

How does it know what a genuine request is? What the client should set
it's poll value is a client decision and that's what we need to decide
how to handle.

> 
>>  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.
> 
> No, this is a different issue, see above.
> 
No, it's the same issue. The client can decide to change it's interval
at any time based on its own needs.

>>> 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.
> 
> No, it would fix the problem, because the KoD RATE packet would always
> have poll 3 (or whatever discard average is configured to) and the
> client's minpoll would stay at 6. Unfortunately, before making this
> change we would need to wait until majority of clients don't shorten
> their polling interval when the KoD poll is smaller. Only ntpd seems
> to be doing 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.
> 
> One packet should stop the client from sending new requests forever?

Yes. Regardless of whether or not the packet is spoofed, it the server
admin doesn't want to receive requests from your client it should be
allowed to say so. This is a Goodbye Kiss.

> If the server configuration is changed later and the address is
> allowed, how will the client know it's allowed to poll the server
> again? I think the effect shouldn't be permanent and authentication
> should be required to prevent a MITM attacker from using these codes.

That's an admin's decision not the client's. There's nothing wrong with
that. If the client thinks it can try again in the future then that
needs to be a human decision and not a computer one.

> 
>>> 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'm not sure what that has to do with the attack. The point of the fix
> is that the client would occasionally get good timestamps and stay
> synchronized. It doesn't matter if the server replies to spoofed
> packets too, the client will ignore them.

That may be but as long as the server is issuing RATE KOD's then it
doesn't know what's genuine and what's not, so if you have 100 spoofed
requests to each genuine one you have a 1/100 chance of replying to a
genuine packet with real data.

> 
>>> Yes, but with the suggested approach client would still occasionally
>>> get good packets with valid timestamps. Only a fraction of the packets
>>> it would get would be KoD packets.
>>>
>>
>> Not really, it would almost certain be dropped as the origin timestamp
>> check would fail.
> 
> Replies to spoofed requests would be dropped, but replies to the
> actual client's requests would be accepted. But we need to make sure
> there are actually some replies to the client's requests, that's 
> what we are trying to fix here.
> 

And as I said above there's a very low chance of getting the server to
respond with valid timestamps to a valid request.

Danny


More information about the hackers mailing list