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

[Florian Weimer]

On 06/12/2014 06:42 PM, Frank Ch. Eigler wrote:
> Florian Weimer <fweimer@redhat.com> 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 sourceware.org/bugzilla 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
   breakage
* 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.

Comments?

-- 
Florian Weimer / Red Hat Product Security