Removing bugs@, adding security@

authentication doesn't protect symmetric associations against DoS attacks

An attacker knowing that NTP hosts A and B are peering with each other (symmetric association) can send a packet to host A with source address of B which will set the NTP state variables on A to the values sent by the attacker. Host A will then send on its next poll to B a packet with originate timestamp that doesn't match the transmit timestamp of B and the packet will be dropped. If the attacker does this periodically for both hosts, they won't be able to synchronize to each other. This is a known denial-of-service attack, described at [1].

According to the document the NTP authentication is supposed to protect symmetric associations against this attack, but that doesn't seem to be the case. The state variables are updated even when authentication fails and the peers are sending packets with originate timestamps that don't match the transmit timestamps on the receiving side.

This seems to be a very old problem, it's in the oldest ntp version I could find (xntp3.3wy). It's also in the NTPv3 (RFC 1305) and NTPv4 (RFC 5905) specifications, so other NTP implementations with support for symmetric associations and authentication may be vulnerable too.

For authentication using symmetric keys it should be sufficient to move the code updating the state variables after the MAC is validated (TEST5). For autokey that's not enough, it seems the attacker can still reset the protocol with crypto-NAK or CRYPTO_ASSOC messages and possibly other ways. I'm not sure if this can be fixed for autokey in general.

[1] https://www.eecis.udel.edu/~mills/onwire.html

Created attachment 1210 [details]
Proposed patch to not update state variables when authentication fails

As Miroslav notes, we'll need to issue an errata against the RFCs.

Fixed in 4.2.8p2 and 4.3.14.

Miroslav is happy with the fix.

It was mentioned that this issue can impact NTPv3 also. However attached patch does not seem to be relevant xntp 3.5 because corresponding code is not there, which is peer->xmt = p_xmt;

Can you please let me know if a patch/fix is available for xntp 3.5

Thanks.

(In reply to comment #7)
> It was mentioned that this issue can impact NTPv3 also. However attached patch
> does not seem to be relevant xntp 3.5 because corresponding code is not there,
> which is peer->xmt = p_xmt;
> 
> Can you please let me know if a patch/fix is available for xntp 3.5
> 
> Thanks.

NTP 3.5 has not been supported for many years. You should upgrade to the latest version of NTP which is currently 4.2.8p2. Is there a reason to fix 3.5 instead of upgrading to the latest version which can at least be supported?

Danny

Thanks Danny for quick response. 

We have commitment to support it for some more time in our products.

If possible can you please help :
- how to know if 3.5 is impacted
- is there any fix available

Thanks for help.

(In reply to comment #9)
> Thanks Danny for quick response. 
> 
> We have commitment to support it for some more time in our products.
> 
> If possible can you please help :
> - how to know if 3.5 is impacted
> - is there any fix available
> 
> Thanks for help.

That version of NTP is something like 20 years old. If you have committed to support the same version what prevents you from providing the upgrade to the latest version? Support could be available for this ancient version but it could not be done for free.

Danny