[prev in list] [next in list] [prev in thread] [next in thread] 

List:       timekeepers
Subject:    Re: [Pool] [ntp:hackers]  NTP CVE patches?
From:       Danny Mayer <mayer () ntp ! org>
Date:       2015-11-09 20:15:47
Message-ID: 5640FEF3.6000004 () ntp ! org
[Download RAW message or body]

On 11/9/2015 4:02 AM, Miroslav Lichvar wrote:
> 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.

I believe this is already fixed. There are cases where TEST2 should not
be performed cause it is not appropriate for that case, such as
Broadcast and Multicast, Symmetric Passive, etc.

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

I think that it is a bit ambiguous to say "continue to increase it each
time it receives a RATE kiss code" in the sense that if it is smaller
that the server wants it should increase its poll interval but it could
be interpreted as increase the poll interval from the last time the
server told it to increase it. The former seems more logical.

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

Not really. It will never know if the server received a reply or dropped
it because it was marked as invalid. Clients don't resend the same
origin timestamp, it will always be new, and it's not going to resend
the servers last transmit timestamp.

Danny
_______________________________________________
pool mailing list
pool@lists.ntp.org
http://lists.ntp.org/listinfo/pool
[prev in list] [next in list] [prev in thread] [next in thread]