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

Danny Mayer mayer at ntp.org
Fri Nov 6 18:38:02 UTC 2015

On 11/6/2015 3:05 AM, Miroslav Lichvar wrote:
> On Thu, Nov 05, 2015 at 04:40:13PM -0500, Danny Mayer wrote:
>>>>  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.
>> No, it's the same issue. The client can decide to change it's interval
>> at any time based on its own needs.
> No, they are two different issues.
> In CVE-2015-7704 the problem is that the client doesn't require TEST2
> to pass for KoD RATE packets, which allows an attacker to send the
> client a spoofed packet that will set the client's minpoll to any
> value. In 4.2.8p4 KoD RATE packets that fail the TEST2 check (which
> compares the origin timestamp to the expected value) are ignored, but
> there is still a case in which the check is not performed at all.

What case would that be?

There are a number of cases where TEST2 should NOT be performed and they
need to be fixed but that's a different problem.

> The issue I was referring to is that the server sets the poll value in
> KoD RATE packets to the maximum of the client's packet poll and the
> rate limiting interval. An attacker can send spoofed packets to the
> server to trigger a KoD reply when the client sends its next request.
> In the BU paper this is described as priming the pump. From the valid
> KoD RATE reply the client will assume the server requires the poll to
> be not shorter than the poll from the client's request, which was set
> to the current poll. The client can't use a shorter poll anymore.

Yes, we still need to figure out what the best poll value should be, but
that needs to come from a packet with a valid origin timestamp and
cannot be carried out by an off-path attacker.

> 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'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.
>> That may be but as long as the server is issuing RATE KOD's then it
>> doesn't know what's genuine and what's not, so if you have 100 spoofed
>> requests to each genuine one you have a 1/100 chance of replying to a
>> genuine packet with real data.
> 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.

>>> 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.
>> And as I said above there's a very low chance of getting the server to
>> respond with valid timestamps to a valid request.
> 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?


More information about the hackers mailing list