EditWYSIWYGAttachPrintable
r4 - 2007-12-21 - 14:44:13 - SteveKosteckeYou 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

We ask people to report security issues regarding the ntp codebase to security@ntp.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:

  • Exactly what is a security issue?
  • 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 | r6 < r5 < r4 < r3 | 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