NetBSD Developer Documentation: Security Issue Handling

Portions of these notes were originally posted by Bill Sommerfeld, acting as security officer, to remind developers how to ensure reliable responses to security issues. Other sections have been added as introductory guidelines.

Handling Security Issues

• If the Security Officers contact you
• Correspondence
• Advisories
• The security-officer can always use help!
• Sequence of events in handling issues

Handling Security Issues

If the Security Officers contact you (top)

When Security issues are brought to the attention of security-officer@NetBSD.org one of the members of that group may initiate contact with (a) developer(s) considered to have expertise in the related area of the system.

Correspondence (top)

• Copy the S-O on all related correspondence. If it is necessary to discuss side issues with other persons, ask them to CC: the S-O as well. Failure to do this could lead to incomplete/incorrect announcements, if the S-O has not had the benefit of understanding all the related issues. In the S-Os own words:

  Please CC: *all* communications about a security issue, regardless of how trivial you think they are, to security-officer@NetBSD.org

• If you have any question about what's going on with an advisory, *ask*. Don't assume. People make mistakes. It's better to tweak the process and people's assumptions so that other people are more likely to catch mistakes.

Advisories (top)

In general, advisories are not sent out for review until they're almost ready to be distributed, and all relevant fixes in question are pulled up to all active release branches. If, when reviewing an advisory, you find something has been missed, message the S-O ASAP

The security-officer can always use help! (top)

Doing the security officer job in an even vaguely close to correct way takes a *LOT* of time. It easily takes four to eight hours, and sometimes more, to do all the miscellaneous work needed to send out a given advisory.

If you find or fix a security issue, please make our jobs as easy as possible, including:

• arranging for pull-ups of the fixes to all active branches
• providing text for the security advisory, or writing the whole thing if at all possible.

Sequence of events in handling issues (top)

• Receive notification of a security issue.
• Investigate the nature of the issue.
• Determine the most appropriate handler(s) for that piece of the tree.
• Contact the handler(s), and get a promised resolution time. (if at all possible)
• Once the fix has been suggested, test it. (handlers may help, but it should be reviewed by someone other than the coder)
• If the issue involves a remote vulnerability, update the public NetBSD servers. In particular, this must be done before any CVS commits! This should happen with 24 hours (preferrably 12 hours or less) of notification being received. If the fix is not ready, apply a stopgap (hack!) fix to close the window of vulnerability.
• Prepare the Security Announcement, describing:
  • The affected components
  • The affected releases
  • The nature of the security violation
  • The method used in closing the vulnerability
• Commit the fix to the CVS repository
• Release the SA to NetBSD and appropriate external mailing-lists.
• Submit the SA for the web pages

Home Page

Developer Documentation