[ntp:hackers] [Pool] NTP CVE patches?
mlichvar at redhat.com
Fri Nov 6 08:05:12 UTC 2015
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.
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.
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.
> > 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
> > 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.
More information about the hackers