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.

Handling Security Issues

(Harlan thinks the following is true. He may be right...)

Please edit this page and add comments or post questions.

We ask people to report security issues regarding the ntp codebase to security@ntp.isc.org .

We ask that people not directly create bugzilla items for security issues.

• What were the reasons for this?
  • I thought one of them was because we were concerned that email might go to bugs@ and we only want it to go to security@
• Are any of them still valid?
• We should consider finding a Security Officer
• Exactly what is the security@ address for?
  • Who should be on that list?

Here are some other issues:

• At what point do we make patches for these issues publically available?
• As we apply commits to ntp-dev or ntp-stable we automatically generate diff email, commit-log email, in addition to publishing the commits.
• At what point can we remove the security restriction on the bugzilla issue?
  • I am inclined to do this when:
    • the (first?) patch for the problem is published in a public repo
    • after the bug is marked RESOLVED/READY

Is this an acceptable way to evolve a fix for a security issue:

• clone a repo to deal with it
• commit patches to this repo
• make dist tarballs as needed to provide to people for testing
• when ready:
  • commit these changes to the parent repo for public release
  • mark the issue as VERIFIED
  • remove the security restriction from the bugzilla issue

Also note that VERIFIED currently means "the published fix works" and we may want to use something else (flags?) to signify when a fix is know to work and is ready to be published. We might be able to use READY for this case.

Note that if this is a problem for ntp-stable then one should follow the normal workflow pattern and clone an ntp-dev repo as well. This includes grabbing changes from the parent repos as needed.

-- HarlanStenn - 25 Aug 2006