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]

Re: Tracking security bugs

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

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

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