Talos Vulnerability Report

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.

Timeline

2015-10-16 - Vendor Disclosure
2016-01-19 - Public Release