Re: Tracking security bugs

[Florian Weimer <fweimer at redhat dot com>]

On 06/23/2014 01:35 PM, Joseph S. Myers wrote:
> > * 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?

If there's a CVE, I guess we have to set security+, set it as an alias 
(if there's just one mapping to this bug), and add it to the summary, at 
the end in parentheses.

For public bugs, CVE assignment has to happen through oss-security.  At 
least one downstream will monitor Bugzilla and request CVEs as 
necessary, or we can do it directly, depending on the number of cases. 
(If there are only very few far and between, it doesn't make sense to 
figure out how to write good CVE requests.)

For the backlog, I will request them myself, in yearly batches, once the 
policy has been fleshed out.

> > * 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.

regex is complicated because crafted patterns can easily tricky 
arbitrary execution times (and perhaps even compilation times).  For 
Basic REs, this is pretty much impossible to change.  (For Extended REs, 
there are several solutions with different trade-offs.)  Consequently, I 
think you'd need process isolation anyway to deal with untrusted regular 
expressions, so deep recursion may not matter in such use cases, it's 
just SIGSEGV instead of SIGXCPU.

I'm not completely sure how to deal with this.  All I can say is that 
it's unlikely I'll be able to fix structural issues in the regex code, 
so I don't feel comfortable labeling any design issues as security bugs.

We probably flag as security+ bugs that are triggered by reasonable, 
real-world patterns with crafted inputs.  Inputs are more likely to 
cross a trust boundary than patterns.

--
Florian Weimer / Red Hat Product Security