What is a security bug?

Most security vulnerabilities in the GNU C Library materialize only after an application uses functionality in a specific way. Therefore, it is sometimes difficult to determine if a defect in the GNU C Library constitutes a vulnerability as such. The follow guidelines can help with a decision.

In this context, "service breakage" means client-side privilege escalation (code execution) or server-side denial of service or privilege escalation through actual, concrete, non-synthetic applications. Or put differently, if the GNU C Library causes a security bug in an application (and the application uses the library in a standard-conforming manner or according to the manual), the GNU C Library bug should be treated as security-relevant.

Reporting private security bugs

All bugs reported in Bugzilla are public.

As a rule of thumb, security vulnerabilities which are exposed over the network or can be used for local privilege escalation (through existing applications, not synthetic test cases) should be reported privately. We expect that such critical security bugs are rare, and that most security bugs can be reported in Bugzilla, thus making them public immediately. If in doubt, you can file a private bug, as explained in the next paragraph.

If you want to report a private security bug that is not immediately public, please contact one of our downstream distributions with security teams. The follow teams have volunteered to handle such bugs:

Please report the bug to just one of these teams. It will be shared with other teams as necessary.

The team you contacted will take care of details such as vulnerability rating and CVE assignment. It is likely that the team will ask to file a public bug because the issue is sufficiently minor and does not warrant an embargo. An embargo is not a requirement for being credited with the discovery of a security vulnerability.

Reporting public security bugs

As mentioned under reporting private security bugs we expect that critical security bugs are rare, and that most security bugs can be reported in Bugzilla, thus making them public immediately. When reporting public security bugs the reporter should provide rationale for their choice of public disclosure.

Triaging security bugs

This section is aimed at developers, not reporters.

Security-relevant bugs should be marked with security+, as per the Bugzilla security flag documentation, following the guidelines above. If you set the security+ flag, you should make sure the following information is included in the bug (usually in a bug comment):

The following links are helpful for finding untriaged bugs:

Fixing security bugs

For changes to master, the regular consensus-driven process must be followed. It makes sense to obtain consensus in private, to ensure that the patch is likely in a committable state, before disclosing an emboargoed vulnerability.

Security backports to release branches need to follow the release process.

Contact the website maintainers and have them draft a news entry for the website frontpage to direct users to the bug, the fix, or the mailing list discussions.

CVE assignment

Security bugs flagged with security+ should have CVE identifiers.

For bugs which are public (thus all bugs in Bugzilla), CVE assignment has to happen through the oss-security mailing list. (Downstreams will eventually request CVE assignment through their public Bugzilla monitoring processes.)

For initially private security bugs, CVEs will be assigned as needed by the downstream security teams. Once a public bug is filed, the name should be included in Bugzilla.

None: Security Process (last edited 2016-02-17 17:16:16 by CarlosODonell)