[ntp:security] [Bug 2781] Security test bug #2

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Fri Mar 6 09:21:37 UTC 2015


http://bugs.ntp.org/show_bug.cgi?id=2781

--- Comment #2 from Miroslav Lichvar <mlichvar at redhat.com> 2015-03-06 09:21:37 UTC ---
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

-- 
Configure bugmail: http://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the security mailing list