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

[Joseph S. Myers]

On Mon, 23 Jun 2014, Florian Weimer wrote:

> 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

Where do CVEs come in here?  Presumably bugs with a CVE should have it 
mentioned in them (even if we think the bug is security- and the CVE is 
bogus).  Should all security+ bugs have a CVE?  At least all new security+ 
bugs?  Who should request such CVEs if wanted?

> * memory leaks and races are security bugs if they cause service
>   breakage

Some interfaces may be expected to have unbounded memory / CPU usage for 
small input, by virtue of the definition of the interface (regex, at 
least).  But the following should still apply to them so they can safely 
be used with resource limits set: they don't leak memory (including in 
cases where they return with an error because an allocation failed); they 
don't do unbounded stack allocations; they don't do buffer overruns (e.g. 
from integer overflow in calculating allocation sizes).  And it is at 
least strongly desirable that they don't have unbounded stack usage 
arising from many individually bounded allocations (e.g. recursion) - 
which can crash the process although it shouldn't be exploitable beyond 
that if less than a page is allocated at a time.

-- 
Joseph S. Myers
joseph@codesourcery.com