NTP BUG 3596: Unauthenticated and unmonitored ntpd may be susceptible to IPv4 attack from highly predictable transmit timestamps
Last update: April 22, 2024 18:49 UTC (7e7bd5857)
Summary
Description
A high-performance ntpd instance that gets its time from unauthenticated IPv4 time sources may be vulnerable to an off-path attacker who can query time from the victim’s ntpd instance. The attacker must be able to send and the victim must be able to receive and process a large number of packets with the spoofed IPv4 address of the upstream server. After 8 or more successful attacks in a row, the attacker can either modify the victim’s clock by a limited amount or cause ntpd to exit. This attack is most effective in cases where an unusually short poll interval is expressly configured on the victim’s ntpd.
Mitigation
- Have enough trustworthy sources of time.
- If you are serving time to a possibly hostile network, have your system get its time from other than unauthenticated IPv4 over the hostile network.
- Use NTP packet authentication where appropriate.
- Pay attention to error messages logged by
ntpd.
- Monitor your
ntpd instances. If the pstats command of ntpq shows the value for “bogus origin” is increasing then that association is likely under attack.
- If you must get unauthenticated time over IPv4 on a hostile network:
- Use
restrict ... noserve to prevent this attack (note that this is a heavy-handed protection), which blocks time service to the specified network.
- Upgrade to 4.2.8p14 or later and appropriately use some or all of the following in your
ntp.conf file:
server ... xmtnoncepool ... xmtnoncerestrict ... serverresponse fuzzpollskewlist default 6|6 (for example)
Credit
Reported by Miroslav Lichvar.
Timeline