This is the mail archive of the
mailing list for the glibc project.
Re: Tracking security bugs
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Jeff Law <law at redhat dot com>, OndÅej BÃlka <neleai at seznam dot cz>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 23 Jun 2014 14:03:03 +0200
- Subject: Re: Tracking security bugs
- Authentication-results: sourceware.org; auth=none
- References: <CANu=DmjYiCT8NRbtdrXXrJtK_-mGRmsN+KUV50oEzaGY7tqn0Q at mail dot gmail dot com> <53973987 dot 90404 at redhat dot com> <y0mr42uxenr dot fsf at fche dot csb> <53A7EA08 dot 3010708 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1406231126350 dot 29418 at digraph dot polyomino dot org dot uk>
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