NTP users are strongly urged to take immediate action to ensure that their NTP daemon is not susceptible to use in a reflected denial-of-service (DRDoS) attack. Please see the NTP Security Notice
for vulnerability and mitigation details, and the Network Time Foundation Blog
for more information. (January 2014)
When we discover a security vulnerability in NTP we first notify institutional members of the NTP Consortium at Network Time Foundation
, then CERT
, and finally make a public announcement.
Reporting Security Issues
Security related bugs, confirmed or suspected, are to be reported by e-mail to email@example.com.
Please refrain from discussing potential security issues in public fora such as the comp.protocols.time.ntp Usenet news-group, our Bug Tracking system, firstname.lastname@example.org, or any other mailing-list.
There are no known unresolved vulnerabilities in NTP at this time.
The following vulnerabilities have been reported for the Reference Implementation of NTP during the 20+ years that the NTP Project
DRDoS / Amplification Attack using ntpdc monlist command
- References: CVE-2013-5211 / VU#348126
- Versions: All releases prior to 4.2.7p26
- Date Resolved: 2010/04/24
- Summary: Unrestricted access to the monlist feature in ntp_request.c in ntpd in NTP before 4.2.7p26 allows remote attackers to cause a denial of service (traffic amplification) via forged (1) REQ_MON_GETLIST or (2) REQ_MON_GETLIST_1 requests, as exploited in the wild in December 2013
- Upgrade to 4.2.7p26 or later.
- Users of versions before 4.2.7p26 should either:
noquery in your default restrictions to block all status queries.
disable monitor to disable the
ntpdc -c monlist command while still allowing other status queries.
DoS attack from certain NTP mode 7 packets
- References: Sec 1331 / CVE-2009-3563 / VU#568372
- Versions: All releases from xntp2 (1989) (possibly earlier) through 4.2.4 before 4.2.4p8 and all versions of 4.2.5
- Date Resolved: Stable (4.2.4p8, 4.2.6) 08 December 2009
- Summary: NTP mode 7 (MODE_PRIVATE) is used by the ntpdc query and control utility. In contrast, ntpq uses NTP mode 6 (MODE_CONTROL), while routine NTP time transfers use modes 1 through 5. Upon receipt of an incorrect mode 7 request or a mode 7 error response from an address which is not listed in a
restrict ... noquery or
restrict ... ignore statement, ntpd will reply with a mode 7 error response (and log a message). In this case:
- If an attacker spoofs the source address of ntpd host A in a mode 7 response packet sent to ntpd host B, both A and B will continuously send each other error responses, for as long as those packets get through.
- If an attacker spoofs an address of ntpd host A in a mode 7 response packet sent to ntpd host A, A will respond to itself endlessly, consuming CPU and logging excessively.
- Upgrade to 4.2.4p8 or 4.2.6, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page.
restrict ... noquery or
restrict ... ignore in your
ntp.conf file to limit the source addresses to which ntpd will respond.
- Filter NTP mode 7 packets coming into and/or going out of your network. This will likely interfere with your ability to use ntpdc to manage NTP servers outside your network, or for a legitimate outsider to manage your servers. (If either of these is useful, a VPN is probably your friend.)
- Filter NTP mode 7 packets where both the source and destination ports are 123, the privileged NTP port. In most cases, legitimate ntpdc mode 7 requests will have a source port not equal to 123 and a destination port of 123, while most legitimate responses will have a source port of 123 and a destination port not equal to 123.
- Employ anti-spoofing IP address filters at your borders to prevent UDP traffic claiming to be from a local address that originate outside your network. Prefer ISPs which employ unicast reverse path filtering (uRPF) to limit the spoofed traffic entering your network. See BCP 38/RFC 2827 and BCP 84/RFC3704 (multihomed networks) for additional details.
- Credit: This vulnerability was discovered by Robin Park and Dmitri Vinokurov of Alcatel-Lucent.
Remote exploit if autokey is enabled
- References: Sec 1151 / CVE-2009-1252 / VU#853097
- Versions: All releases from 4.0.99m/4.1.70 (2001-08-15) through 4.2.4 before 4.2.4p7 and 4.2.5 before 4.2.5p74
- Date Resolved: Stable (4.2.4p7) 4 Mar 2009, Development (4.2.5p74) 10 Sep 2007
- Summary: 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.
- Credit: This vulnerability was discovered by Chis Ries of CMU.
Multiple OpenSSL signature verification API misuse
- References: oCERT #2008-016 / CVE-2009-0021
- Versions: 4.2.4 before 4.2.4p5 and 4.2.5 before 4.2.5p150
- Date resolved: Stable (4.2.4p6) 8 Jan 2009, Development (4.2.5p151) 23 Dec 2008
- Summary: Affected versions do not properly check the return value from the OpenSSL EVP_VerifyFinal function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature, a different vulnerability than CVE-2008-5077 and CVE-2009-0025.
Buffer overflow in ntp_control:ctl_getitem() function
- References: CVE-2001-0414 / VU#970472 / BID:2450
- Versions affected: 4.0.99k and earlier (aka xntpd and xntp3)
- Date resolved: 13 Jun 2001
- Summary: Buffer overflow in ntpd ntp daemon 4.0.99k and earlier (aka xntpd and xntp3) allows remote attackers to cause a denial of service and possibly execute arbitrary commands via a long readvar argument.
Internal overflow if date / time offset is greater than 34 years
- References: CAN-2004-0657 / VU#584606
- Versions affected: versions prior to 4.0
- Date resolved: July 1999
- Summary: Integer overflow in the NTP daemon (NTPd) before 4.0 causes the NTP server to return the wrong date/time offset when a client requests a date/time that is more than 34 years away from the server's time.