Critical #NTP Vulnerability in ntpd prior to 4.2.8

Published: 2014-12-20
Last Updated: 2014-12-20 13:44:16 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

The Google security team discovered several vulnerabilities in current NTP implementations, one of which can lead to arbitrary code execution [1][2]. NTP servers prior to version 4.2.8 are affected. 

There are some rumors about active exploitation of at least some of the vulnerabilities Google discovered.

Make sure to patch all publicly reachable NTP implementations as fast as possible. 

Mitigating Circumstances: 

Try to block inbound connections to ntp servers who do not have to be publicly reachable. However, be aware that simple statefull firewalls may not track UDP connections correctly and will allow access to internal NTP servers from any external IP if the NTP server recently established an outbound connection.

ntpd typically does not have to run as root. Most Unix/Linux versions will configure NTP using a lower privileged users.

According to the advisory at, you can also:

Disable Autokey Authentication by removing, or commenting out, all configuration directives beginning with the crypto keyword in your ntp.conf file.

A few Ubuntu and CentOS systems I tested, as well as OS X systems, do not seem to use autokey. 


CVE Impact Details
CVE-2014-9293 authentication ntp will create a weak key if none is provided in the configuration file.
CVE-2014-9294 authentication ntp-keygen uses a weak seed to create random keys
CVE-2014-9295 remote code execution 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.
CVE-2014-9296 missing error message In the NTP code, a section of code is missing a return, and the resulting error indicates processing did not stop.


Johannes B. Ullrich, Ph.D.

1 comment(s)


Did they ever fix the silent crash bug in 4.2.7? I'm still on 4.2.6. Good thing I stopped letting the public access my NTP server... The 200,000 connection packet floods were getting excessive.

Diary Archives