r2 - 2016-01-08 - 05:04:48 - HarlanStennYou are here: NTP >  Main Web > SecurityNotice > NtpBug2956
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 2956


  • Date Resolved: Stable (4.2.8p5) 07 Jan 2016; Dev (4.3.78) 07 Nov 2015
  • References: Sec 2956 / CVE-2015-5300
  • Affects: All ntp-4 releases up to, but not including 4.2.8p5, and 4.3.0 up to, but not including 4.3.78
  • CVSS3: (AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:N/A:L) Base Score: 4.0, MEDIUM
  • Summary: If ntpd is always started with the -g option, which is common and against long-standing recommendation, and if at the moment ntpd is restarted an attacker can immediately respond to enough requests from enough sources trusted by the target, which is difficult and not common, there is a window of opportunity where the attacker can cause ntpd to set the time to an arbitrary value. Similarly, if an attacker is able to respond to enough requests from enough sources trusted by the target, the attacker can cause ntpd to abort and restart, at which point it can tell the target to set the time to an arbitrary value if and only if ntpd was re-started against long-standing recommendation with the -g flag, or if ntpd was not given the -g flag, the attacker can move the target system's time by at most 900 seconds' time per attack.
  • Mitigation:
  • Credit: This weakness was discovered by Aanchal Malhotra, Isaac E. Cohen, and Sharon Goldberg at Boston University.

NOTE WELL: The -g flag disables the limit check on the panic_gate in ntpd, which is 900 seconds by default. The bug identified by the researchers at Boston University is that the panic_gate check was only re-enabled after the first change to the system clock that was greater than 128 milliseconds, by default. The correct behavior is that the panic_gate check should be re-enabled after any initial time correction.

If an attacker is able to inject consistent but erroneous time responses to your systems via the network or "over the air", perhaps by spoofing radio, cellphone, or navigation satellite transmissions, they are in a great position to affect your system's clock. There comes a point where your very best defenses include:

  • Configure ntpd to get time from multiple sources.
  • Monitor your ntpd instances.

-- SueGraves - 2016-01-08

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | 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-2021 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