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.

NTP Bug 3071

Client rate limiting and server responses

• Date Resolved: 21 Nov 2016
• References: Sec 3071 / CVE-2016-7426 / VU#633847
• Affects: ntp-4.2.5p203, up to but not including ntp-4.2.8p9, and ntp-4.3.0 up to, but not including ntp-4.3.94.
• CVSS2: LOW 1.0 (AV:L/AC:H/Au:S/C:N/I:N/A:P)
• CVSS3: LOW 1.6 CVSS:3.0/AV:P/AC:H/PR:H/UI:R/S:U/C:N/I:N/A:L
• Summary: When ntpd is configured with rate limiting for all associations (restrict default limited in ntp.conf), the limits are applied also to responses received from its configured sources. An attacker who knows the sources (e.g., from an IPv4 refid in server response) and knows the system is (mis)configured in this way can periodically send packets with spoofed source address to keep the rate limiting activated and prevent ntpd from accepting valid responses from its sources.
  
  While this blanket rate limiting can be useful to prevent brute-force attacks on the origin timestamp, it allows this DoS attack. Similarly, it allows the attacker to prevent mobilization of ephemeral associations.
• Mitigation:
  • Implement BCP-38.
  • If you choose to use restrict default limited ..., be sure to use restrict source ... (without limited) to avoid this attack.
  • Properly monitor your ntpd instances, and auto-restart ntpd (without -g) if it stops running.
• Credit: This weakness was discovered by Miroslav Lichvar of Red Hat.