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.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

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

Reporting Security Issues

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

Exactly what is a security issue?

• See SecurityIssueDefinition.

Life Cycle of Security Issues

• Get report
  • If the reporter registers at our bugzilla we can easily keep them in the loop
  • Using security bugs also consolidates the information in the right places and gets the right people involved
• Validate report
• Start working on the fix
• Determine its CVSS Score: http://nvd.nist.gov/cvss.cfm
• Request a CVE: email cve@mitre.org and ask for a CVE Identifier
• Write up the CVE report
  • Include CVSS Score: http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2
    eg: "CVSS Score: Base 6.1, adjusted for lack of targets, score is 1.5 (AV:N/AC:L/Au:N/C:N/I:N/A:C/E:P/RL:O/RC:C/TD:L)"
• Inform NTP Forum Institutional Members
• Inform CERT
• Schedule the release
• ...

Discussion and Related Issues

We (used to) 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