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 overloaded). > > 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. -- Miroslav Lichvar _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
