[ntp:hackers] [Pool] NTP CVE patches?
mlichvar at redhat.com
Wed Nov 4 08:15:50 UTC 2015
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.
> > 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.
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
> 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.
> > 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?
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.
> > 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.
> > 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.
More information about the hackers