An exploitable denial of service vulnerability exists in the trap functionality of ntpd. If an ntpd instance is configured to send traps, a specially crafted network packet can be used to cause a null pointer dereference resulting in a denial of service. This vulnerability can be triggered by a remote unauthenticated attacker.
CVSSv2: 7.1 - (AV:N/AC:M/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
When reporting traps, the ntpd reportevent(err, peer, str) function asserts that peer != NULL if err is a "peer event". Thus if reportevent() can be called with NULL peer parameter, ntpd will abort() causing a DoS condition.
ntp-4.2.8p7 introduced a variety of validity checks on crypto-NAK packets to address the nak-dos vulnerability (CVE-2016-1547). When any of these validity checks fail, ntpd reports an event to any trap receivers with: reportevent(PEVNTAUTH, peer, "Invalid_NAK").
If the source address and mode of the incoming crypto-NAK packet do not correspond to an existing peer, the peer argument will be NULL causing the INSIST(peer != NULL) assertion to fail when report_event() attempts to report the event to its trap recipients.
It may also be possible to trigger reporting of a peer event without a valid peer on other code paths. For example, checkleapsec() in ntptimer.c calls:
report_event(PEVNT_ARMED, sys_peer, NULL);
If ntpd's syspeer advertises a leap second and then the host running ntpd becomes temporarily disconnected, it may be possible for checkleapsec() to be called without a valid sys_peer leading to the assertion failure above.
This crash can be reliably triggered on ntp-4.2.8p8. We are reporting this defect against NTPsec 0.9.3 as well because it contains the same incorrect logic in reportevent(). However we did not attempt to exploit this vulnerability on NTPsec because triggering a call to reportevent() with a NULL peer is not as straightforward as with ntp-4.2.8p8.
The fix for CRYPTO_NAK crash (CVE-2016-4957) introduced in ntp-4.2.8p8 does not address this vulnerability.
Though traps are not configured in most common NTP environments, attackers can employ "Network Time Protocol Control Mode Unauthenticated Trap Information Disclosure and DDoS Amplification Vulnerability" (TALOS-2016-0203) in order to configure a trap in order to exploit this vulnerability.
Successful exploitation of this vulnerability requires ntpd to be configured with trap recipients. Systems can be protected by removing all "trap" commands from ntp.conf and adopting the mitigations for "Network Time Protocol Control Mode Unauthenticated Trap Information Disclosure and DDoS Amplification Vulnerability" (TALOS-2016-0203).
2016-09-20 - Vendor Disclosure
2016-11-21 - Public Release
Discovered by Matthew Van Gundy of Cisco ASIG.