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

Miroslav Lichvar mlichvar at redhat.com
Tue Nov 3 08:51:13 UTC 2015

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.

> > 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.

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.

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. 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.

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.

Alternatively, the client could be modified to handle KoD RATE packets
by adjusting its polling interval only temporarily and ignore the KoD
poll value.

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 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 configutable.

> > 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.

> 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.

Miroslav Lichvar

More information about the hackers mailing list