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.8p10 was released on 21 March 2017. It addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

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: http://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-2017 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