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.
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 email@example.com
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
- Request a CVE: email firstname.lastname@example.org and ask for a CVE Identifier
- Write up the CVE report
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-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
then one should follow the normal workflow pattern and clone an
repo as well. This includes grabbing changes from the parent repos as needed.
- 25 Aug 2006