NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.



ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.



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

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

June 2020 ntp-4.2.8p15 NTP Release and Security Vulnerability Announcement

The NTP Project at Network Time Foundation publicly released ntp-4.2.8p15 on Tuesday, 23 June 2020.

ntpd

This release fixes one security issue in

MEDIUM: Sec 3661: Memory leak with CMAC keys Systems that use a CMAC algorithm in ntp.keys will not release a bit of memory on each packet that uses a CMAC key, eventually causing ntpd to run out of memory and fail. The CMAC cleanup from https://bugs.ntp.org/3447, part of ntp-4.2.8p11 and ntp-4.3.97 , introduced a bug whereby the CMAC data structure was no longer completely removed. Reported by Martin Burnicki of Meinberg.



and provides 13 bugfixes.

ENotification of these issues were delivered to our Institutional members on a rolling basis as they were reported and as progress was made.

2020 Jun 23: Public release

2020 Apr 12: First Release to Advance Security Partners

2020 Apr 07: Notification to Institutional Members

2020 Apr 01: Notification from reporter

Timeline:

March 2020 ntp-4.2.8p14 NTP Release and Security Vulnerability Announcement

The NTP Project at Network Time Foundation publicly released ntp-4.2.8p14 on Tuesday, 03 March 2020.

ntpd

This release fixes three security issues in

NONE: Sec 3610: process_control() should bail earlier on short packets. Reported by Philippe Antoine (Catena cyber with oss-fuzz).

should bail earlier on short packets. MEDIUM: Sec 3596: Unauthenticated ntpd may be susceptible to IPv4 spoof attack from highly predictable transmit timestamps. Reported by Miroslav Lichvar.

MEDIUM: Sec 3592: DoS Attack on unauthenticated client. The fix for https://bugs.ntp.org/3445 introduced a bug whereby a system that is running ntp-4.2.8p12 (possibly earlier) or p13 that only has one unauthenticated time source can be attacked in a way that causes the victim's next poll to its source to be delayed, for as long as the attack is maintained. Reported by Miroslav Lichvar.



and provides 46 bugfixes and addresses 4 other issues.

ENotification of these issues were delivered to our Institutional members on a rolling basis as they were reported and as progress was made.

2020 Mar 03: Public release (barring as yet unforeseen issues)

2020 Feb 17: Release to Advance Security Partners

2019 Jun 05: Notification to Institutional Members

2019 May 30: Notification of Sec 3592 from reporter

Timeline:

March 2019 ntp-4.2.8p13 NTP Release and Security Vulnerability Announcement

The NTP Project at Network Time Foundation publicly released ntp-4.2.8p13 on Thursday, 07 March 2019.

ntpd

This release fixes one security issue in

MEDIUM: Sec 3565: Crafted null dereference attack from a trusted source with an authenticated mode 6 packet A crafted malicious authenticated mode 6 ( ntpq ) packet from a permitted network address can trigger a NULL pointer dereference, crashing ntpd . Note that for this attack to work, the sending system must be on an address that the target's ntpd accepts mode 6 packets from, and must properly authenticate the packet with a private key that is specifically listed as being used for mode 6 authorization. Reported by Magnus Stubman.



and provides 17 bugfixes and 1 other improvement.

ENotification of these issues were delivered to our Institutional members on a rolling basis as they were reported and as progress was made.

2019 Mar 07: Public release

2019 Feb 20: Release to Advance Security Partners

2019 Jan 16: Notification to Institutional Members

2019 Jan 15: Notification from reporter

Timeline:

August 2018 ntp-4.2.8p12 NTP Release and Security Vulnerability Announcement

The NTP Project at Network Time Foundation publicly released ntp-4.2.8p12 on Tuesday, 14 August 2018.

ntpd

This release improves on one security issue in

LOW/MEDIUM: Sec 3012: Sybil vulnerability: ephemeral association attack While fixed in ntp-4.2.8p7 and with significant additional protections for this issue in 4.2.8p11, ntp-4.2.8p12 includes a fix for an edge case in the new noepeer support. Originally reported by Matt Van Gundy of Cisco. Edge-case hole reported by Martin Burnicki of Meinberg.



ntpq

ntpdc

one security issue inand

LOW: Sec 3505: The openhost() function used during command-line hostname processing by ntpq and ntpdc can write beyond its buffer limit. Reported by Fakhri Zulkifli.

function used during command-line hostname processing by and can write beyond its buffer limit.

and provides 27 bugfixes and 4 other improvements.

ENotification of these issues were delivered to our Institutional members on a rolling basis as they were reported and as progress was made.

2018 Aug 14: Public release

2018 Jul 25: Release to Advance Security Partners

Timeline:

February 2018 ntp-4.2.8p11 NTP Security Vulnerability Announcement

The NTP Project at Network Time Foundation is releasing ntp-4.2.8p11.

ntpd

This release addresses five security issues in

ntpq

one security issue in

MEDIUM: Sec 3414 / CVE-2018-7183 / VU#961909: ntpq:decodearr() can write beyond its buffer limit Reported by Michael Macnair of Thales-esecurity.com.



and provides over 33 bugfixes and 32 other improvements.

ENotification of these issues were delivered to our Institutional members on a rolling basis as they were reported and as progress was made.

2018 Feb 27: Public release

2018 Feb 21: VU number assigned. NEWS file updated.

2018 Feb 20: CVE numbers assigned. NEWS file updated. Tarball updated. CERT notified.

2018 Feb 12: Release to Advance Security Partners containing security fixes for Bugs 3453 and 3454, and FIPS and multicast regressions.

2018 Feb 07: Regressions reported for FIPS and multicast mode.

2018 Feb 05: Bugs 3453 and 3454 reported.

2018 Jan 23: Initial release to Advance Security Partners.

Timeline:

March 2017 ntp-4.2.8p10 NTP Security Vulnerability Announcement

NTF's NTP Project is releasing ntp-4.2.8p10, which addresses:

6 MEDIUM severity vulnerabilities (1 is about the Windows PPSAPI DLL)

5 LOW severity vulnerabilities (2 are in the Windows Installer)

4 Informational-level vulnerabilities

15 other non-security fixes and improvements

All of the security issues in this release are listed in VU#633849

ntp-4.2.8p10 was released on 21 March 2017.

ENotification of these issues were delivered to our Institutional members on a rolling basis as they were reported and as progress was made.

2017 Mar 21: Public release

2017 Mar 13: CERT notified

2017 Mar 06: Release to Advance Security Partners

2017 Mar 06: Announcement to Institutional Members

2017 Feb 09: Mozilla/Cure53 audit received

Timeline:

November 2016 ntp-4.2.8p9 NTP Security Vulnerability Announcement (HIGH for Windows, MEDUIM otherwise)

NTF's NTP Project is releasing ntp-4.2.8p9, which addresses:

1 HIGH severity vulnerability that only affects Windows

2 MEDIUM severity vulnerabilities

2 MEDIUM/LOW severity vulnerabilities

5 LOW severity vulnerabilities

28 other non-security fixes and improvements

All of the security issues in this release are listed in VU#633847

ntp-4.2.8p9 is currently scheduled to be released on 21 November 2016.

NTP Consortium members at the Partner and Premier levels received access to these patches on 14 November 2016. Notification of these issues were delivered to these members on a rolling basis as they were reported and as progress was made.

CERT was notified as the reports came in, and was given our software release notification on 15 November 2016.

Public release on 21 November 2016.

June 2016 ntp-4.2.8p8 NTP Security Vulnerability Announcement (HIGH)

NTF's NTP Project has been notified of the following 1 high- and 4 low-severity vulnerabilities, which are fixed in ntp-4.2.8p8.

ntp-4.2.8p8 is scheduled to be released on 2 June 2016.

160602: ntp-4.2.8p8 released.

160526: CERT notification, including availability of pre-release patches. See: https://www.kb.cert.org/vuls/id/321640

160524: NTP Consortium members at the Partner and Premier levels received pre-release patch access.

Timeline:

April 2016 ntp-4.2.8p7 Security Vulnerability Announcement (Medium)

NTF's NTP Project has been notified of the following 4 low- and 7 medium-severity vulnerabilities that are fixed in ntp-4.2.8p7, released on Tuesday, 26 April 2016:

NtpBug3012 - Sybil vulnerability: ephemeral association attack - MITIGATION ONLY

NtpBug2978 - Interleave pivot - MITIGATION ONLY

The following issues already listed above are "Mitigation only" and are expected to be fully resolved in an upcoming release.

NtpBug2936 - Skeleton Key

NtpBug2901 - Clients that receive a KoD should validate the origin timestamp field

The following issues were fixed in earlier releases and contain improvements in this p7 release:

160426: ntp-4.2.8p7 released.

160418: pre-release patch availability announced to CERT.

160418: CERT notified.

160412: pre-release patches sent to authorized NTP Consortium members.

160221: CVE numbers requested from Mitre.

160219: Initial notification from Qihoo/360. Analysis begins.

160214: Advance notification sent to authorized NTP Consortium members.

160112: Initial notification from Cisco. Analysis begins.

Timeline:

January 2016 NTP-4.2.8p6 Security Vulnerability Announcement (Medium)

NTF's NTP Project has been notified of the following low- and medium-severity vulnerabilities that are fixed in ntp-4.2.8p6, released on Tuesday, 19 January 2016:

Additionally, mitigations are published for the following two issues:

Bug 2947 / CVE-2015-8140: ntpq vulnerable to replay attacks Reported by Cisco ASIG

vulnerable to replay attacks Bug 2946 / CVE-2015-8139: Origin Leak: ntpq and ntpdc , disclose origin Reported by Cisco ASIG, discovered by Boston University

and , disclose origin

160119: ntp-4.2.8p6 released.

160118: pre-release patch availability announced to CERT.

160118: CERT notified.

160117: pre-release patches sent to authorized NTP Consortium members.

151123: CVE numbers requested from Mitre.

151105: Advance notification sent to authorized NTP Consortium members.

151016: Initial notification from Cisco. Analysis begins.

Timeline:

January 2016 NTP-4.2.8p5 Security Vulnerability Announcement (Medium)

NTF's NTP Project has been notified of the following 1 medium-severity vulnerability that is fixed in ntp-4.2.8p5, released on Thursday, 7 January 2016:

ntp-4.2.8p5 also fixes:

October 2015 NTP-4.2.8p4 Security Vulnerability Announcement (Medium)

Timeline:* 160107: ntp-4.2.8p5 released.* 160104: pre-release patch availability announced to CERT.* 1601xx: CERT notified.* 160104: pre-release patches sent to authorized NTP Consortium members.* 1510xx: CVE numbers requested from Mitre.* 151016: Advance notification sent to authorized NTP Consortium members.* 151008: Initial notification of 2935-2941. Analysis begins.

NTF's NTP Project has been notified of the following 13 low- and medium-severity vulnerabilities that are fixed in ntp-4.2.8p4, released on Wednesday, 21 October 2015:

The only generally-exploitable bug in the above list is the crypto-NAK bug, which has a CVSS2 score of 6.4.

Additionally, three bugs that have already been fixed in ntp-4.2.8 but were not fixed in ntp-4.2.6 as it was EOL'd have a security component, but are all below 1.8 CVSS score, so we're reporting them here:

Bug 2382: Peer precision < -31 gives division by zero

Bug 1774: Segfaults if cryptostats enabled when built without OpenSSL

enabled when built without OpenSSL Bug 1593: ntpd abort in free() with logconfig syntax error

151021: ntp-4.2.8p4 released.

151020: CERT & Mitre updated with final drafts of announcement

151019: NAK bug addition and new CVE#'s announced to CERT.

151017: Advance notification of NAK bug being added was sent to authorized NTP Consortium members..

151014: pre-release patch availability announced to CERT.

151009: notification of public release date change to 21Oct sent to members and reporters and Mitre

151006: pre-release patches sent to authorized NTP Consortium members.

150826: Initial notification of 2909. Analysis begins.

150826: CVE number clarification requested from Mitre.

150826: Advance notification sent to authorized NTP Consortium members for 1593,1774, 2382, 2899, 2902.

150820: Initial notification of 2902. Analysis begins.

150811: Initial notification of 2899. Analysis begins.

Timeline:

June 2015 NTP-4.2.8p3 Security Vulnerability Announcement (Minor)

NTF's NTP Project has been notified of a minor vulnerability in the processing of a crafted remote-configuration packet. Remote configuration is disabled by default. This issue was discovered and reported byAleksis Kauppinen of Codenomicon.

ntpd control message crash: Crafted NUL-byte in configuration directive.

Timeline

20150629: Public release of patch and vulnerability details/

20150624: Initial supplemental patch made available to NTF's NTP Consortium's Advance Security Patch members.

20150622: Notification to NTF's NTP Consortium's Advance Security Notification list.

20150616: Notification received from FICORA. Analysis begins.

20150512: 4.2.8p3-RC1 released.

20150501: 4.3.25 released.

April 2015 NTP-4.2.8p2 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.

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 .

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

Timeline:

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.

up to but not including 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.

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: Upgrade to 4.2.8p2 , or later, from the NTP Project Download Page or the NTP Public Services Project Download Page Configure ntpd with enough time sources and monitor it properly.

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.

up to but not including 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.

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.

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.

December 2014 NTP-4.2.8p1 Security Vulnerability Announcement

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

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.

file. ntp-keygen before 4.2.7p230 used a non-cryptographic random number generator with a weak seed to generate symmetric keys.

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.

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.

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.

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 a rare error condition case in 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.

packet value in 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.

packet value is not validated in several code paths in which can lead to information leakage or a possible crash of ntpd. Mitigation - any of: Upgrade to 4.2.8p1, 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 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!

offer the same protection for 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 addresses from the outside. This is not really a bug in NTP, it's a problem with some OSes. If you have one of these OSes where can be spoofed, -based ACL restrictions on application can be bypassed! Mitigation: Upgrade to 4.2.8p1, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page Install firewall rules to block packets claiming to come from ::1 from inappropriate network interfaces.

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.

key is set in the configuration file, 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) 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: Upgrade to 4.2.7p11, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page. Put restrict ... noquery in your ntp.conf file, for non-trusted senders.

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() .

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 from OpenSSL, or . Mitigation - any of: Upgrade to 4.2.7p230, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page. Put restrict ... noquery in your ntp.conf file, for non-trusted senders.

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.

file contains a 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.

is missing a 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: Upgrade to 4.2.8, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page or Remove or comment out all configuration directives beginning with the crypto keyword in your ntp.conf file.

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.

or statement, ntpd will reply with a mode 7 error response (and log a message). In this case: 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.

file contains a 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.

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