[ntp:hackers] [Pool] NTP CVE patches?
mlichvar at redhat.com
Mon Nov 9 09:02:15 UTC 2015
On Fri, Nov 06, 2015 at 01:38:02PM -0500, Danny Mayer wrote:
> On 11/6/2015 3:05 AM, Miroslav Lichvar wrote:
> > there is still a case in which the check is not performed at all.
> What case would that be?
The case where one of the checks performed before this one fails, but
doesn't reject the packet. I thought I explained it in the private
discussion we had couple weeks ago about this. The fix I think is to
either always perform TEST2 for KoD packets or drop them when any of
the other tests failed assuming TEST2 was not performed.
> > It's not a big deal and the fix is simple. Unfortunately, it will
> > probably need to wait until ntpd as a client is fixed to not violate
> > the RFC (increasing the polling rate when the received KoD poll is
> > small) and this fixed version is widely used.
> It does NOT violate the RFC.
I think it does. The description of the RATE code in the section 7.4.,
to which you were referring before, currently says:
For kiss code RATE, the client MUST immediately increase its
polling interval to that server and continue to increase it
each time it receives a RATE kiss code.
It doesn't explain how exactly should be the polling interval
increased, but I think it's clear it doesn't allow the client to
immediatelly reduce its interval as ntpd does when the KoD RATE poll
and the configured minpoll are both smaller than the current host
> > Right. But look at it from the client's point of view. It's still
> > getting good replies to a fraction of its queries and this fraction
> > doesn't change with the attacker's sending rate (until the network is
> > overloaded).
> It would likely be days before a real reply to the target systems
> request would come through with valid timestamps and that's not likely
> to help the situation.
That only depends on the rate limiting configuration. It the server
responded on average once per eight request (to match the maximum
number of consecutive measurements that can be dropped in the ntpd
clock filter), with the default maximum polling interval of 1024
seconds the average server response interval would be about 2 hours.
> > Yes, but there is probably nothing that could be done about it. The
> > server could try to track all NTP clients (not SNTP) by saving the tx
> > timestamps and comparing them to the client's org timestamps, but that
> > would basically turn it into something like TCP and bring all the
> > problems it has.
> Huh? When the server gets the packet there's only one timestamp in the
> packet and that's the senders "origin" timestamp (spoofed or otherwise).
> So what does it have to compare it against?
NTP (but not necessarily SNTP) clients set the origin timestamp in
their requests to the transmit timestamp from the previous server
reply. If the server saved its transmit timestamps it could check if
the client received the previous reply and therefore know the request
is not from a spoofed IP address.
More information about the hackers