Talos Vulnerability Report
Network Time Protocol ntpq and ntpdc Infinite Loop Vulnerability
January 19, 2016
ntpq processes incoming packets in a loop in getresponse(). The loop’s only stopping conditions are receiving a complete and correct response or hitting a small number of error conditions. If the packet contains incorrect values that don’t trigger one of the error conditions, the loop continues to receive new packets. ntpdc suffers from the same issue.
This can be leveraged by an attacker to DoS an ntpq or ntpdc client by creating an infinite loop. As long as the incoming packets are not correct and don’t trigger an error condition, the loop will never end.
CVSSv2: 6.1 - AV:A/AC:L/Au:N/C:N/I:N/A:C
CVSSv3: 5.9 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
For example, if an attacker causes response packets to contain an NTP version of 5, the processing loop will continue back to the top when it checks the version number. As long as the attacker continues to send packets with NTP version 5 in them, the ntpq client will never stop receiving packets and therefore never return from getresponse().
This type of attack requires the attacker to do one of the following:
- Own a malicious NTP server that the client trusts
- Prevent a legitimate NTP server from sending packets to the ntpq client
- MITM the ntpq communications between the ntpq client and the NTP server
If an attacker can manage to prevent an NTP server from sending ntpq responses, they can spoof responses from any machine with network access to the client and ntpq will process them.
It appears ntpdc has a similar problem. Rather than running in a loop with no exit condition, it uses goto to jump back to a label.
Ideally, the loop which receives packets would have some type of fallback terminating condition that does not depend on the incoming packets.
This defect was discovered by Jonathan Gardner of Cisco ASIG.
2015-10-16 - Vendor Disclosure
2016-01-19 - Public Release