Last updated 25 August 2025

Buffer overflow in the decodearr function in ntpq in ntp 4.2.8p6 through 4.2.8p10 allows remote attackers to execute arbitrary code by leveraging an ntpq query and sending a response with a crafted array.

Crypto-NAK packets in ntpd in NTP 4.2.x before 4.2.8p4, and 4.3.x before 4.3.77 allows remote attackers to bypass authentication.

The datalen parameter in the refclock driver in NTP 4.2.x before 4.2.8p4, and 4.3.x before 4.3.77 allows remote attackers to execute arbitrary code or cause a denial of service (crash) via a negative input value.

A flaw was found in the way NTP handled rate limiting. An attacker able to send a large number of crafted requests to an NTP server could trigger the rate limiting on that server, and prevent clients from getting a usable reply from the server.

The default NTP configuration in Red Hat Enterprise Linux does not enable rate limiting.

External References:

https://www.cs.bu.edu/~goldbe/NTPattack.html

Buffer overflow in the password management functionality in NTP 4.2.x before 4.2.8p4, and 4.3.x before 4.3.77 allows remote authenticated users to cause a denial of service (daemon crash) or possibly execute arbitrary code via a crafted key file.

The following flaw was found in ntpd:

An exploitable use-after-free vulnerability exists in the password management functionality of the Network Time Protocol. A specially crafted key file could cause a buffer overflow resulting in memory corruption. An attacker could provide a malicious password file to trigger this vulnerability.

External References:

http://talosintel.com/reports/TALOS-2015-0054/ http://support.ntp.org/bin/view/Main/SecurityNotice#October2015NTPSecurityVulner

Last updated 24 July 2024

Last updated 24 July 2024

Network Time Protocol (NTP), as specified in RFC 5905, uses port 123 even for modes where a fixed port number is not required, which makes it easier for remote attackers to conduct off-path attacks.

Buffer overflow in the legacy Datum Programmable Time Server (DPTS) refclock driver in NTP before 4.2.8p10 and 4.3.x before 4.3.94 allows local users to have unspecified impact via a crafted /dev/datum device.

ntp. Multiple issues were addressed by updating to version 4.2.8p10

ntp. Multiple issues were addressed by updating to version 4.2.8p10

NTP 4.x before 4.2.8p6 and 4.3.x before 4.3.90 do not verify peer associations of symmetric keys when authenticating packets, which might allow remote attackers to conduct impersonation attacks via an arbitrary trusted key, aka a "skeleton key."

As per upstream NTP security advisory, multiple buffer overflows were reported in ntp daemon, details provided below

Buffer overflow in cryptorecv()

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. This vulnerability was discovered by Stephen Roettger of the Google Security Team.

Mitigation: Disable Autokey Authentication by removing, or commenting out, all configuration directives beginning with the crypto keyword in your ntp.conf file.

Buffer overflow in ctlputdata()

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. This vulnerability was discovered by Stephen Roettger of the Google Security Team.

Buffer overflow in configure()

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. This vulnerability was discovered by Stephen Roettger of the Google Security Team.

As per upstream NTP security advisory:

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 RANDbytes from OpenSSL, or arc4random().

Mitigation: Upgrade to 4.2.7p230 or later.

This vulnerability was discovered in ntp-4.2.6 by Stephen Roettger of the Google Security Team.

As per upstream NTP security advisory:

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) ntprandom() function, which was seeded with a 32-bit value and could only provide 32 bits of entropy. This was sufficient back in the late 1990s when the code was written. Not today.

Mitigation: Upgrade to 4.2.7p11 or later.

This vulnerability was noticed in ntp-4.2.6 by Neel Mehta of the Google Security Team.

A vulnerability was found in NTP. A security issue which enables an off-path attacker to prevent ntpd from synchronizing with NTP servers not using authentication. A server mode packet with spoofed source address sent to the client ntpd causes the next transmission to be rescheduled, even if the packet doesn't have a valid origin timestamp. If the packet is sent to the client frequently enough, it will stop polling the server and not be able to synchronize with it.

Last updated 25 August 2025

It was found that when NTP is configured in broadcast mode, an off-path attacker could broadcast packets with bad authentication (wrong key, mismatched key, incorrect MAC, etc) to all clients. The clients, upon receiving the malformed packets, would break the association with the broadcast server. This could cause the time on affected clients to become out of sync over a longer period of time.

Upstream patch:

https://github.com/ntp-project/ntp/commit/fe46889f7baa75fc8e6c0fcde87706d396ce1461

A memory leak flaw was found in ntpd's CRYPTOASSOC. If ntpd is configured to use autokey authentication, an attacker could send packets to ntpd that would, after several days of ongoing attack, cause it to run out of memory.

Mitigation:

Disable NTP autokey authentication by removing, or commenting out, all configuration directives beginning with the 'crypto' keyword in your ntp.conf file.

External References:

https://github.com/ntp-project/ntp/blob/stable/NEWS#L91 http://support.ntp.org/bin/view/Main/SecurityNotice#October2015NTPSecurityVulner

It was found that the fix for CVE-2014-9750 was incomplete: three issues were found in the value length checks in ntpcrypto.c, where a packet with particular autokey operations that contained malicious data was not always being completely validated. Receipt of these packets can cause ntpd to crash.

Upstream patch:

https://github.com/ntp-project/ntp/commit/c4cd4aaf418f57f7225708a93bf48afb2bc9c1da

Mitigation:

Disable NTP autokey authentication by removing, or commenting out, all configuration directives beginning with the 'crypto' keyword in your ntp.conf file.

External References:

https://github.com/ntp-project/ntp/blob/stable/NEWS#L11 http://support.ntp.org/bin/view/Main/SecurityNotice#October2015NTPSecurityVulner

Last updated 25 August 2025

Last updated 25 August 2025

It was discovered that sntp program would hang in an infinite loop when a crafted NTP packet was received, related to the conversion of the precision value in the packet to double.

It was found that ntpd exits with a segmentation fault when a statistics type that was not enabled during compilation (e.g. timingstats) is referenced by the statistics or filegen configuration command, for example:

ntpq -c ':config statistics timingstats' ntpq -c ':config filegen timingstats'

Upstream patch:

http://bk.ntp.org/ntp-dev/?PAGE=patch&REV=4d253ed0A400LyhRQIV0u23NJwuGAA

(in 4.2.6, the code than handles NULL == filegen needs to be adjusted as the outer loop was changed from while to for)

It was found that ntpd could crash due to an uninitialized variable when processing malformed logconfig configuration commands, for example:

ntpq -c ":config logconfig a"

Upstream patch:

http://bk.ntp.org/ntp-dev/?PAGE=patch&REV=4c4fc141LwvcoGp-lLGhkAFp3ZvtrA

The ntpd client in NTP 4.x before 4.2.8p4 and 4.3.x before 4.3.77 allows remote attackers to cause a denial of service via a number of crafted "KOD" messages.

The cryptoxmit function in ntpd in NTP 4.2.x before 4.2.8p4, and 4.3.x before 4.3.77 allows remote attackers to cause a denial of service (crash). NOTE: This vulnerability exists due to an incomplete fix for CVE-2014-9750.

It was found that ntpd did not correctly implement the -g option:

-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the thresh‐ old is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options.

ntpd could actually step the clock multiple times by more than the panic threshold if its clock discipline doesn't have enough time to reach the sync state and stay there for at least one update. If a man-in-the-middle attacker can control the NTP traffic since ntpd was started (or maybe up to 15-30 minutes after that), they can prevent the client from reaching the sync state and force it to step its clock by any amount any number of times, which can be used by attackers to expire certificates, etc.

This is contrary to what the documentation says. Normally, the assumption is that an MITM attacker can step the clock more than the panic threshold only once when ntpd starts and to make a larger adjustment the attacker has to divide it into multiple smaller steps, each taking 15 minutes, which is slow.