r23 - 2014-12-19 - 14:07:21 - HarlanStennYou are here: NTP >  Main Web > SecurityNotice
NTF needs your help to qualify to participate in the Combined Federal Campaign so we can continue our mission to improve Network Time. We only need a few thousand dollars more by December 31st - any sized donation helps! Please join an NTF Consortium or make a donation to NTF now! THANKS!

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 security@ntp.org.

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

Active Vulnerabilities

NTF's NTP Project has been notified of a number of vulnerabilities from Neel Mehta and Stephen Roettger of Google's Security Team. The two most serious of these issues and four less serious issues have been resolved as of ntp-4.2.8, which was released on 18 December 2014. There are still two less significant issues to be addressed. We're expecting to fix these within the next month.

Resolved Vulnerabilities

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

Weak default key in config_auth()

  • References: Sec 2665 / CVE-2014-9293 / VU#852879
  • CVSS: (AV:N/AC:L/Au:M/C:P/I:P/A:C) Base Score: 7.3
  • Versions: All NTP4 releases before 4.2.7p11
  • Date Resolved: Dev (4.2.7p11) 28 Jan 2010
  • Summary: 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) ntp_random() function, which was seeded with a 32 bit value and can only provide 32 bits of entropy. This was sufficient back in the late 1990s when this code was written. Not today.
  • Mitigation:
  • Credit: This vulnerability was discovered in ntp-4.2.6 by Neel Mehta of the Google Security Team.

non-cryptographic random number generator with weak seed used by ntp-keygen to generate symmetric keys

  • References: Sec 2666 / CVE-2014-9294 / VU#852879
  • CVSS: (AV:N/AC:L/Au:M/C:P/I:P/A:C) Base Score: 7.3
  • Versions: All NTP4 releases before 4.2.7p230
  • Date Resolved: Dev (4.2.7p230) 01 Nov 2011
  • Summary: 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 RAND_bytes from OpenSSL, or arc4random().
  • Mitigation:
  • Credit: This vulnerability was discovered in ntp-4.2.6 by Stephen Roettger of the Google Security Team.

Buffer overflow in crypto_recv()

  • References: Sec 2667 / CVE-2014-9295 / VU#852879
  • CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5
  • Versions: All releases before 4.2.8
  • Date Resolved: Stable (4.2.8) 18 Dec 2014
  • 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:
  • Credit: This vulnerability was discovered by Stephen Roettger of the Google Security Team.

Buffer overflow in ctl_putdata()

Buffer overflow in configure()

receive(): missing return on error

  • References: Sec 2670 / CVE-2014-9296 / VU#852879
  • Versions: All NTP4 releases before 4.2.8
  • CVSS: (AV:N/AC:L/Au:N/C:N/I:N/A:P) Base Score: 5.0
  • Date Resolved: Stable (4.2.8) 18 Dec 2014
  • Summary: Code in ntp_proto.c:receive() is 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.
  • Mitigation:
  • Credit: This vulnerability was discovered by Stephen Roettger of the Google Security Team.

Older Resolved Issues

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:
  • 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.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r23 < r22 < r21 < r20 < r19 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2014 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback