CVE-2020-11868: NTP Denial of Service Vulnerability

CVE-2020-11868 Overview

CVE-2020-11868 is a denial of service vulnerability in the Network Time Protocol daemon (ntpd) that allows an off-path attacker to block unauthenticated time synchronization. The vulnerability exists in ntp versions before 4.2.8p14 and 4.3.x versions before 4.3.100, where the daemon improperly handles server mode packets with spoofed source IP addresses. The flaw allows attackers to disrupt NTP synchronization by sending crafted packets that lack valid origin timestamps, causing the daemon to reschedule transmissions inappropriately.

Critical Impact

Successful exploitation can prevent systems from synchronizing time with NTP servers, potentially causing authentication failures, log inconsistencies, certificate validation issues, and disruption of time-sensitive operations across enterprise infrastructure.

Affected Products

• NTP versions prior to 4.2.8p14
• NTP 4.3.x versions prior to 4.3.100
• Red Hat Enterprise Linux 7.0
• NetApp Data ONTAP (7-mode)
• NetApp Clustered Data ONTAP
• NetApp HCI Management Node and SolidFire
• NetApp VASA Provider for Clustered Data ONTAP
• NetApp Virtual Storage Console for vSphere
• NetApp Fabric-Attached Storage 8300, 8700, and A400 series
• NetApp All Flash Fabric-Attached Storage 8300, 8700, and A400 series
• Debian Linux 8.0
• openSUSE Leap 15.1 and 15.2

Discovery Timeline

• 2020-04-17 - CVE-2020-11868 published to NVD
• 2025-05-05 - Last updated in NVD database

Technical Details for CVE-2020-11868

Vulnerability Analysis

This vulnerability stems from improper validation of origin timestamps in server mode NTP packets. The ntpd implementation fails to properly verify the authenticity of incoming packets before acting on them, specifically when processing server mode responses. When an attacker sends a spoofed packet that appears to originate from a legitimate NTP server, the daemon processes the packet even though it lacks a valid origin timestamp.

The core issue is that ntpd reschedules its transmission attempts when receiving these malformed packets. This behavior can be exploited by an off-path attacker who does not need to be positioned between the NTP client and server. By continuously sending spoofed server mode packets, an attacker can effectively prevent the victim system from ever successfully synchronizing with its configured NTP servers.

This vulnerability is classified under CWE-346 (Origin Validation Error), as the fundamental flaw involves inadequate verification of packet source authenticity before processing the packet content.

Root Cause

The root cause is insufficient origin timestamp validation in the NTP packet processing logic. When ntpd receives a server mode packet, it should verify that the origin timestamp in the response matches a previously sent request. However, vulnerable versions of ntpd reschedule transmission attempts even when this validation fails, allowing attackers to manipulate synchronization timing through spoofed packets.

The protocol implementation assumes that server mode packets with matching source IPs are legitimate, without adequately verifying the cryptographic or temporal authenticity of the packet contents. This design assumption can be exploited when IP spoofing is possible.

Attack Vector

The attack is network-based and can be executed by an off-path attacker, meaning the attacker does not need to intercept legitimate traffic between the NTP client and server. The attacker crafts server mode NTP packets with:

1. A spoofed source IP address matching the victim's configured NTP server
2. Invalid or missing origin timestamps
3. Appropriate NTP mode and version fields

These packets are sent to the victim's NTP client on UDP port 123. When the victim processes these packets, even though they lack valid origin timestamps, the client reschedules its transmission attempts. By continuously sending these spoofed packets, the attacker can indefinitely block time synchronization.

The attack requires no authentication and no user interaction. The attacker only needs to know or guess the IP addresses of the victim and their NTP server, along with network access to reach the victim on UDP port 123.

Detection Methods for CVE-2020-11868

Indicators of Compromise

• Unusual NTP traffic patterns with high volumes of server mode packets from unexpected sources
• NTP synchronization failures or persistent "unsynchronized" status on affected systems
• Log entries indicating repeated NTP transmission rescheduling without successful synchronization
• Discrepancies between system time and authoritative time sources

Detection Strategies

• Monitor NTP daemon logs for repeated synchronization failures or unusual rescheduling events
• Implement network-level monitoring for NTP traffic anomalies, including server mode packets from non-configured server addresses
• Deploy intrusion detection rules to identify NTP packets with mismatched or invalid origin timestamps
• Use network flow analysis to detect unusual patterns of NTP traffic targeting specific hosts

Monitoring Recommendations

• Enable verbose logging on NTP daemons to capture synchronization state changes and packet processing events
• Configure alerting for extended periods of NTP unsynchronization status
• Implement network segmentation monitoring to detect NTP traffic from unauthorized sources
• Establish baseline NTP traffic patterns and alert on significant deviations

How to Mitigate CVE-2020-11868

Immediate Actions Required

• Update NTP to version 4.2.8p14 or later for the 4.2.x branch
• Update NTP to version 4.3.100 or later for the 4.3.x branch
• Review and apply vendor-specific patches from NetApp, Red Hat, Debian, and openSUSE as applicable
• Implement network-level filtering to restrict NTP traffic to known, authorized servers
• Consider enabling NTP authentication using symmetric keys or Autokey where supported

Patch Information

The NTP Project has released patched versions addressing this vulnerability. Version 4.2.8p14 and 4.3.100 include fixes that properly validate origin timestamps before rescheduling transmissions. Detailed information about the fix is available in the NTP Bug #3592 Overview.

Vendor-specific patches are available from:

• Red Hat Bug #1716665 Details
• NetApp Security Advisory 20200424
• Debian LTS Security Notice
• Gentoo GLSA 202007-12
• Oracle CPU July 2021 Alert

Workarounds

• Implement firewall rules to restrict incoming NTP traffic on UDP port 123 to only known, trusted NTP servers
• Use BCP 38/RFC 2827 ingress filtering at network boundaries to prevent IP address spoofing
• Deploy NTP authentication to cryptographically validate server responses where feasible
• Consider using multiple diverse NTP sources to reduce single-point-of-failure risk
• Monitor system time drift and implement alerting for synchronization failures

# Example iptables rules to restrict NTP traffic to trusted servers
# Replace NTP_SERVER_1 and NTP_SERVER_2 with your authorized NTP server IPs

iptables -A INPUT -p udp --sport 123 -s NTP_SERVER_1 -j ACCEPT
iptables -A INPUT -p udp --sport 123 -s NTP_SERVER_2 -j ACCEPT
iptables -A INPUT -p udp --sport 123 -j DROP

# Verify NTP version (ensure 4.2.8p14+ or 4.3.100+)
ntpd --version