[ntp:hackers] [Pool] NTP CVE patches?
mayer at ntp.org
Tue Nov 3 19:45:25 UTC 2015
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:
>>> 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.
> 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.
>>> 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 the description of what a client is supposed to do when KoD
> RATE is received could be more detailed.
Most of that needs to be a policy decision rather than a rule. Different
implementations need to be possible especially if someone comes up with
a better idea of how to handle the situation.
> A maximum for the poll value accepted from KoD RATE packets would be a
> good idea. I think a good limit would be the default maximum poll (10).
> FWIW, that's the limit used in chrony.
The problem here is that you may want to consider what the max poll
interval is for the specific server as specified in the conf file which
could easily be one day because they only contact NIST once per day, or
it might be interplanetary so long intervals are expected. Or the admin
has set the max poll so small that you can't effectively use it. So the
problem is one of balancing these conflicting requirements and still
deal with the rate issue.
> 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.
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 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.
> Alternatively, the client could be modified to handle KoD RATE packets
> by adjusting its polling interval only temporarily and ignore the KoD
> poll value.
While this is better, it doesn't solve the problem since the attacker
can continue as above.
> 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
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.
>> 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.
>>> 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.
> 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.
>> 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.
> The number of pool servers the client can switch to is not infinite.
> In some zones the number is small. The attacker can send spoofed
> packets to all servers the client was/is/will be using.
True enough but it's better than nothing.
More information about the hackers