r8 - 2011-05-27 - 16:16:27 - HarlanStennYou are here: NTP >  Dev Web > HandlingSecurityIssues
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

Reporting Security Issues

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

Exactly what is a security issue?

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: https://nvd.nist.gov/cvss.cfm
  • Request a CVE: email cve@mitre.org and ask for a CVE Identifier
  • Write up the CVE report
  • 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

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r8 < r7 < r6 < r5 < r4 | 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-2022 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