TALOS-2016-0080
Network Time Protocol ntpq and ntpdc Infinite Loop Vulnerability
Jan 19, 2016
Report IDs
CVE-2015-8158
CERT VU#357792
Summary
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.
Tested Versions
ntp 4.2.8p3
NTPsec aa48d001683e5b791a743ec9c575aaf7d867a2b0c
Product URLs
http://www.ntp.org
http://www.ntpsec.org/
CVSS Score
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
Details
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.
Recommended Fix
Ideally, the loop which receives packets would have some type of fallback terminating condition that does not depend on the incoming packets.
Credit
This defect was discovered by Jonathan Gardner of Cisco ASIG.
Timeline
2015-10-16 - Vendor Disclosure
2016-01-19 - Public Release