Security Notice

Notification Policy

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 protected].

Please refrain from discussing potential security issues in public fora such as the comp.protocols.time.ntp Usenet news-group, our Bug Tracking system, [email protected], or any other mailing-list.

Active Vulnerabilities

Resolved Vulnerabilities

The following vulnerabilities have been reported for the Reference Implementation of NTP during the 20+ years that the NTP Project has existed.

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
• Mitigation:
  • Upgrade to 4.2.7p26 or later.
  • Users of versions before 4.2.7p26 should either:
    • Use noquery in your default restrictions to block all status queries.
    • Use 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.
• Mitigation:
  • 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.
  • Use 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.
• Mitigation:
  • Upgrade to 4.2.4p7 or 4.2.5p74, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page
  • Disable Autokey Authentication by removing, or commenting out, all configuration directives beginning with the crypto keyword in your ntp.conf file.
• 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.