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

Danny Mayer mayer at ntp.org
Tue Oct 27 13:56:49 UTC 2015


On 10/26/2015 5:38 AM, Miroslav Lichvar wrote:
> On Sat, Oct 24, 2015 at 01:09:06AM +0000, Harlan Stenn wrote:

>> It may be that the server operator should stop using 'restrict kod
>> limited'.  But it's their choice to use it, and it was the client's
>> choice to use that server.
> 
> Are you saying clients should be able to detect if the server is
> vulnerable to this attack and avoid it? That doesn't seem right to me.
> 
> If the rate limiting as currently implemented is vulnerable, I think
> it should be either removed or fixed. It seems in DNS they were able
> to fix it.
> 

The situation with DNS is very different as dropping packets has very
little effect on the ability of applications to get the needed address
since they have other ways of getting it. Timestamps on the other hand
need multiple packets to establish a reliability profile for a server
and regular exchange of packets with that server.

>>> I think it also creates a new problem that an attacker could spam the
>>> client's syslog with these messages and fill the disk. Harlan, could
>>> you please consider adding a rate limit for the message to prevent
>>> that?
>>
>> How far do we go?  syslogd already has code for clogging attackss.
> 
> Which is used on all systems supported by ntp and the rate limiting
> is enabled by default there? Wouldn't this be useful for an attacker
> to hide important information, like clock being stepped or peers
> becoming unreachable?
> 
> The point is that as far as I know it wasn't possible to trigger a log
> message with a spoofed packet before and now it is. The users should
> at least be warned about this.
> 

Do you have an alternative suggestion on how to deal with this so that
the admin has a chance of know that his/her server know that it may be
under attack?

>> If the client is the victim of a DoS attack from forged sources, that's
>> something to report to the server operator and network operators.
> 
> Realistically, what they can do about it?
> 

Not knowing is worse.

>>> As for fixing the CVE, the NTPattack paper suggests to not drop all
>>> packets from rate limited clients, but reply randomly (similarly to
>>> RRL in DNS) to some percentage of the requests that appear to be
>>> coming from the client, so it will not be completely starved.
>>
>> KoD packets do not have valid time stamps, so this won't work.  What
>> might work is to have a % of these KoD RATE response get answered.  But
>> there are problems with this too, if the source IP is being forged.
> 
> The proposal is to reply only to a fraction of the requests (chosen
> randomly) if restrict limited is enabled and the limit is reached.
> If also restrict kod is enabled, the fraction of the replies (chosen
> randomly) would be KoD RATE packets, but most of the replies the
> client would get would still be useful for synchronization.
> 
But if this was a KoD RATE attack the origin timestamp will still be
wrong as far as the receiving client is concerned. The server doesn't
know if the request packet is from the client or has been spoofed so how
does it decide whether or not to reply with valid information to any
specific request?

> There would be a change in the case of abusive clients though.
> Currently, if a client is always sending its requests too frequently
> and it doesn't fall off the monitoring list, it will get only KoD
> replies, which don't have the server's time. I think the intention was
> to let such clients drift away from true time, the user notice the
> clock is wrong, investigate the problem and get the implementation
> fixed. I'm wondering if that ever happened.

I suspect that depends on whether the admin is good or is just too busy
with other work to notice. Normally NTP is a setup and forget type of
application. It normally doesn't need any maintenance so it doesn't get
on a list of things for an admin to check on any regular basis.

> 
>> The best idea I've had is that if a client is getting unexpected replies
>> from a server that it send a query packet before the server might start
>> to send KoD responses, as there's a decent chance that the server might
>> soon stop responding to packets claiming to be from the client/target IP.
> 
> I'm not sure how would that help. When the client gets a reply to a
> spoofed request, it may already be blocked and it won't get any
> further replies to its own requests. Also, couldn't be this behavior
> (sending new request when a bad reply is received) exploited for some
> other attacks?

Harlan was talking about receiving an unexpected packet from a server
before it starts sending a KoD. The first time an attacker sends a
spoofed packet the receiving client notes that it hadn't sent it and
sends it's own packet to the server. The chances are that it will get
back a valid response before the server has decided to KoD the IP address.

> 
>> Also think about the consequences of what you are proposing - the
>> suggestion is that if a KoD RATE is received, there's a chance that if
>> we just ask often enough, we'll eventually get a valid response.  This
>> will *encourage* more traffic to a server for non-compliant NTP clients.
> 

Actually you need to ask infrequently otherwise it may as well be just
another KoD response.

> Yes, that is a possibility. It would definitely need to be tested
> first on a public server to see how the clients react when they are
> under the attack and get responses only to a fraction of their
> requests.
> 

Danny


More information about the hackers mailing list