As per upstream NTP security advisory, multiple buffer overflows were reported in ntp daemon, details provided below
Buffer overflow in cryptorecv()
When Autokey Authentication is enabled (i.e. the ntp.conf file contains a 'crypto pw ...' directive) a remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process. This vulnerability was discovered by Stephen Roettger of the Google Security Team.
Mitigation: Disable Autokey Authentication by removing, or commenting out, all configuration directives beginning with the crypto keyword in your ntp.conf file.
Buffer overflow in ctlputdata()
A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process. This vulnerability was discovered by Stephen Roettger of the Google Security Team.
Buffer overflow in configure()
A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process. This vulnerability was discovered by Stephen Roettger of the Google Security Team.
As per upstream NTP security advisory:
Prior to ntp-4.2.7p230 ntp-keygen used a weak seed to prepare a random number generator that was of good quality back in the late 1990s. The random numbers produced was then used to generate symmetric keys. In ntp-4.2.8 we use a current-technology cryptographic random number generator, either RANDbytes from OpenSSL, or arc4random().
Mitigation: Upgrade to 4.2.7p230 or later.
This vulnerability was discovered in ntp-4.2.6 by Stephen Roettger of the Google Security Team.
As per upstream NTP security advisory:
If no 'auth' key is set in the configuration file, ntpd would generate a random key on the fly. There were two problems with this: 1) the generated key was 31 bits in size, and 2) it used the (now weak) ntprandom() function, which was seeded with a 32-bit value and could only provide 32 bits of entropy. This was sufficient back in the late 1990s when the code was written. Not today.
Mitigation: Upgrade to 4.2.7p11 or later.
This vulnerability was noticed in ntp-4.2.6 by Neel Mehta of the Google Security Team.
A vulnerability was found in NTP. A security issue which enables an off-path attacker to prevent ntpd from synchronizing with NTP servers not using authentication. A server mode packet with spoofed source address sent to the client ntpd causes the next transmission to be rescheduled, even if the packet doesn't have a valid origin timestamp. If the packet is sent to the client frequently enough, it will stop polling the server and not be able to synchronize with it.
It was discovered that sntp program would hang in an infinite loop when a crafted NTP packet was received, related to the conversion of the precision value in the packet to double.
It was found that ntpd exits with a segmentation fault when a statistics type that was not enabled during compilation (e.g. timingstats) is referenced by the statistics or filegen configuration command, for example:
ntpq -c ':config statistics timingstats' ntpq -c ':config filegen timingstats'
Upstream patch:
http://bk.ntp.org/ntp-dev/?PAGE=patch&REV=4d253ed0A400LyhRQIV0u23NJwuGAA
(in 4.2.6, the code than handles NULL == filegen needs to be adjusted as the outer loop was changed from while to for)
It was found that ntpd could crash due to an uninitialized variable when processing malformed logconfig configuration commands, for example:
ntpq -c ":config logconfig a"
Upstream patch:
http://bk.ntp.org/ntp-dev/?PAGE=patch&REV=4c4fc141LwvcoGp-lLGhkAFp3ZvtrA
The monlist feature in ntprequest.c in ntpd in NTP before 4.2.7p26 allows remote attackers to cause a denial of service (traffic amplification) via forged (1) REQMONGETLIST or (2) REQMONGETLIST1 requests, as exploited in the wild in December 2013.
As per upstream NTP security advisory:
Code in ntpproto.c:receive() was missing a 'return;' in the code path where an error was detected, which meant processing did not stop when a specific rare error occurred. We haven't found a way for this bug to affect system integrity. If there is no way to affect system integrity the base CVSS score for this bug is 0. If there is one avenue through which system integrity can be partially affected, the base score becomes a 5. If system integrity can be partially affected via all three integrity metrics, the CVSS base score become 7.5.
This vulnerability was discovered by Stephen Roettger of the Google Security Team.
Mitigation:
Remove or comment out all configuration directives beginning with the crypto keyword in your ntp.conf file.