This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Tracking security bugs (was: Re: Requesting CVEs for glibc security issues)

On 06/12/2014 06:42 PM, Frank Ch. Eigler wrote:
Florian Weimer <> writes:

[...]  Would it be possible to add a tristate security flag to
Bugzilla, with states "security bug", "not a security bug", "don't
know/not yet triaged" (obviously with better/shorter names)?  [...]
security-lated states. [...]

OK, added a "security" flag to the instance
to give this a try.

Thanks. I've browsed Bugzilla a bit and would like to propose the following rules for tracking security bugs:

* bugs with security impact are flagged as "security+"
* bugs without direct security impact get "security-"
* duplicate bugs of security bugs generally get "security-"
* bugs which are still unprocessed have no flag
* security? can be used for tricky cases

For security+ bugs, we should make sure that the affected version range is apparent from the bug report. (If the first vulnerable version is very old, it is not necessary to track it down because version numbering was somewhat inconsistent back then.)

It's often tricky to decide what constitutes security impact. Based on what I've seen in Bugzilla, here are some guidelines:

* buffer overflows should be treated as security bugs
* same for bugs that cause memory corruption which is likely
  exploitable, or somewhat likely information disclosure
* memory leaks and races are security bugs if they cause service
* bugs in aio and cancellation are security-relevant to the extend they
  cause service breakage
* bugs that cripple the whole system (so that it doesn't even boot or
  does not run most applications) are not security bugs because they
  won't exploitable due to general system instability.
* bugs that crash nscd are generally security bugs, except if they
  can only be triggered by a trusted data source (DNS is not trusted,
  but NIS and LDAP probably are)

In this context, "service breakage" means client-side privilege escalation (code execution) or server-side denial of service or privilege escalation of actual, concrete, non-synthetic applications. Or put differently, if glibc causes a security bug in an application, the glibc bug should be treated as security-relevant.

I'm not sure what to do about bugs in threading primitives, such as a mutexes that do not always achieve mutual exclusion (even if properly used). I'm leaning towards "service breakage only".

Regarding reporting procedures, I would like to create a Wiki page that suggests that potentially critical bugs are reported to downstream security teams. (I know that this already happens with Debian and Red Hat and would list them as suggested contact points, if SuSE, Canonical or any other distribution wants to chip in, feel free.) From there, it will be shared using the usual channels, or (more likely) the downstream security team will downgrade the bug and suggest filing it publicly. We should make clear that the lack of an embargo does not preclude downstream security updates and advisories, and the usual credits that come with them.


Florian Weimer / Red Hat Product Security

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]