This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Tracking security bugs (was: Re: Requesting CVEs for glibc security issues)
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Will Newton <will dot newton at linaro dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, 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 10:49:12 +0200
- Subject: Tracking security bugs (was: Re: Requesting CVEs for glibc security issues)
- 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>
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