r31 - 2015-04-08 - 04:58:40 - HarlanStennYou are here: NTP >  Main Web > SecurityNotice
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to use in a distributed denial-of-service (DDoS) attack. Please also take this opportunity to defeat denial-of-service attacks by implementing ingress and Egress filtering through BCP38.

ntp-4.2.8p2, released on 7 April 2015, addresses two issues with crafted packets involving symmetric key encryption and Message Authentication Codes.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

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.

Security Patch Policy

When security patches are ready, they are first given to Premier and Partner Institutional members of the NTP Consortium at Network Time Foundation, then access instructions are provided to CERT, and finally the public release is made on the embargo date.

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.

Recent Vulnerabilities

April 2015 NTP Security Vulnerability Announcement

NTF's NTP Project has been notified of two vulnerabilities in the processing of crafted packets using private key authentication. These issues were discovered and reported by Miroslav Lichvar of Red Hat.

  • Bug 2279: ntpd accepts unauthenticated packets with symmetric key crypto.
  • Bug 2281: Authentication doesn't protect symmetric associations against DoS attacks.

CERT and Mitre have been notified, and CVE/VU numbers have been assigned.

NTP Consortium members at the Partner and Premier levels received access to patches that resolve these issues on 22 March 2015.

These issues (along with other bugfixes and improvements) will be released on 7 April 2015 in ntp-4.2.8p2 .

Timeline:

  • 150407: ntp-4.2.8p2 released.
  • 150329: pre-release patch availability announced to CERT.
  • 150323: CERT assigns VU#374268 to these issues.
  • 150322: pre-release patches sent to authorized NTP Consortium members.
  • 150317: CVSS scoring collaboration requested.
  • 150317: CERT notified.
  • 150316: Red Hat provides CVE-2015-1798 for NtpBug2779 , and CVE-2015-2781 for NtpBug2781 .
  • 150315: Advance notification sent to authorized NTP Consortium members.
  • 150315: Mitre tells us to get the CVE numbers from Red Hat.
  • 150313: CVE numbers requested from Mitre.
  • 150306: Initial notification of 2779 and 2781. Analysis begins.

ntpd accepts unauthenticated packets with symmetric key crypto.

  • References: Sec 2779 / CVE-2015-1798 / VU#374268
  • Affects: All NTP4 releases starting with ntp-4.2.5p99 up to but not including ntp-4.2.8p2 where the installation uses symmetric keys to authenticate remote associations.
  • CVSS: (AV:A/AC:M/Au:N/C:P/I:P/A:P) Base Score: 5.4
  • Date Resolved: Stable (4.2.8p2) 07 Apr 2015
  • Summary: When ntpd is configured to use a symmetric key to authenticate a remote NTP server/peer, it checks if the NTP message authentication code (MAC) in received packets is valid, but not if there actually is any MAC included. Packets without a MAC are accepted as if they had a valid MAC. This allows a MITM attacker to send false packets that are accepted by the client/peer without having to know the symmetric key. The attacker needs to know the transmit timestamp of the client to match it in the forged reply and the false reply needs to reach the client before the genuine reply from the server. The attacker doesn't necessarily need to be relaying the packets between the client and the server.

    Authentication using autokey doesn't have this problem as there is a check that requires the key ID to be larger than NTP_MAXKEY, which fails for packets without a MAC.
  • Mitigation:
  • Credit: This issue was discovered by Miroslav Lichvar, of Red Hat.

Authentication doesn't protect symmetric associations against DoS attacks.

  • References: Sec 2781 / CVE-2015-1799 / VU#374268
  • Affects: All NTP releases starting with at least xntp3.3wy up to but not including ntp-4.2.8p2 where the installation uses symmetric key authentication.
  • CVSS: (AV:A/AC:M/Au:N/C:P/I:P/A:P) Base Score: 5.4
    Note: the CVSS base Score for this issue could be 4.3 or lower, and it could be higher than 5.4.
  • Date Resolved: Stable (4.2.8p2) 07 Apr 2015
  • Summary: An attacker knowing that NTP hosts A and B are peering with each other (symmetric association) can send a packet to host A with source address of B which will set the NTP state variables on A to the values sent by the attacker. Host A will then send on its next poll to B a packet with originate timestamp that doesn't match the transmit timestamp of B and the packet will be dropped. If the attacker does this periodically for both hosts, they won't be able to synchronize to each other. This is a known denial-of-service attack, described at https://www.eecis.udel.edu/~mills/onwire.html .

    According to the document the NTP authentication is supposed to protect symmetric associations against this attack, but that doesn't seem to be the case. The state variables are updated even when authentication fails and the peers are sending packets with originate timestamps that don't match the transmit timestamps on the receiving side.

    This seems to be a very old problem, dating back to at least xntp3.3wy. It's also in the NTPv3 (RFC 1305) and NTPv4 (RFC 5905) specifications, so other NTP implementations with support for symmetric associations and authentication may be vulnerable too. An update to the NTP RFC to correct this error is in-process.
  • Mitigation:
    • Upgrade to 4.2.8p2, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page
    • Note that for users of autokey, this specific style of MITM attack is simply a long-known potential problem.
    • Configure ntpd with appropriate time sources and monitor ntpd. Alert your staff if problems are detected.
  • Credit: This issue was discovered by Miroslav Lichvar, of Red Hat.

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.

The remaining two issues are addressed by 4.2.8p1, which was released on 4 February 2015

December 2014 NTP Security Vulnerability Announcement

NTF's NTP Project has been notified of a number of vulnerabilities from Neel Mehta and Stephen Roettger of Google's Security Team.

  • We have been generating a weak default key if no authentication key is defined in the ntp.conf file.
  • ntp-keygen before 4.2.7p230 used a non-cryptographic random number generator with a weak seed to generate symmetric keys.
  • It's possible to overflow a stack buffer in crypto_recv() when using autokey and potentially allow malicious code to be executed with the privilege level of the ntpd process.
  • It's possible to overflow a buffer in ctl_putdata() and potentially allow malicious code to be executed with the privilege level of the ntpd process.
  • It's possible to overflow a buffer in configure() and potentially allow malicious code to be executed with the privilege level of the ntpd process.
  • A missing return; in a rare error condition case in ntp_proto.c:receive() will cause a temporary association to become mobilized. While we haven't yet found a way this can be exploited, an exploit might be possible.
  • In several places, the vallen packet value in ntp_crypto.c is not validated, which can lead to information leakage.
  • If ::1 is spoofed on some OSes, the packet is processed instead of being dropped, so ACLs based on IPv6 ::1 addresses can be bypassed. This could allow an attacker to tell your ntpd to, among other things, reconfigure itself.

Additionally, we are working to patch the known deficiencies in NTP's Autokey protocol, as a stop-gap measure until the Network Time Security draft (which will replace Autokey) is ready to be deployed. These weaknesses were discovered by Dieter Sibold, PhD of PTB, and Stephen Roettger of the Google Security Team.

vallen is not validated in several places in ntp_crypto.c, leading to a potential info leak or possibly crashing ntpd.

  • References: Sec 2671 / CVE-2014-9297 / VU#852879
  • Affects: All NTP4 releases before 4.2.8p1 that are running autokey.
  • CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5
  • Date Resolved: Stable (4.2.8p1) 04 Feb 2015
  • Summary: The vallen packet value is not validated in several code paths in ntp_crypto.c which can lead to information leakage or a possible crash of ntpd.
  • Mitigation - any of:
  • Credit: This vulnerability was discovered by Stephen Roettger of the Google Security Team, with additional cases found by Sebastian Krahmer of the SUSE Security Team and Harlan Stenn of Network Time Foundation.

::1 can be spoofed on some OSes, so ACLs based on IPv6 ::1 addresses can be bypassed.

  • References: Sec 2672 / CVE-2014-9298 / VU#852879
  • Affects: All NTP4 releases before 4.2.8p1, under at least some versions of MacOS and Linux. *BSD has not been seen to be vulnerable.
  • CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:C) Base Score: 9
  • Date Resolved: Stable (4.2.8p1) 04 Feb 2015
  • Summary: While available kernels will prevent 127.0.0.1 addresses from "appearing" on non-localhost IPv4 interfaces, some kernels do not offer the same protection for ::1 source addresses on IPv6 interfaces. Since NTP's access control is based on source address and localhost addresses generally have no restrictions, an attacker can send malicious control and configuration packets by spoofing ::1 addresses from the outside. Note Well: This is not really a bug in NTP, it's a problem with some OSes. If you have one of these OSes where ::1 can be spoofed, ALL ::1 -based ACL restrictions on any application can be bypassed!
  • Mitigation:
  • Credit: This vulnerability was discovered by Stephen Roettger of the Google Security Team.

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 - any of:
  • 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 - any of:
  • 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 - any of:
    • Upgrade to 4.2.8, 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.
    • Put restrict ... noquery in your ntp.conf file, for non-trusted senders.
  • 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

April 2010: 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.

December 2009: 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.

March 2009/September 2007: 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.

January 2009: 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.

June 2001: 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.

July 1999: 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: r31 < r30 < r29 < r28 < r27 | 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-2015 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