[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.64.1306271712580.4601@faron.mitre.org>
Date: Thu, 27 Jun 2013 17:37:09 -0400 (EDT)
From: "Steven M. Christey" <coley@...re.org>
To: oss-security@...ts.openwall.com, kseifried@...hat.com,
alexandre.rebert@...il.com
cc: Russ Allbery <rra@...nford.edu>, cve-assign@...re.org
Subject: Re: 1.2k bug reports for Debian, some may be security
On Thu, 27 Jun 2013, Kurt Seifried wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/26/2013 11:56 PM, Russ Allbery wrote:
>> Kurt Seifried <kseifried@...hat.com> writes:
>>
>>> I will of course be doing CVEs for these (*sob*). In order to
>>> make this possible though I'm going to need some help in the form
>>> of good CVE requests in this case I will be fascist.
The following is just my opinion and not an official CVE-Assign position.
I am concerned that we could assign too many CVEs to issues that don't
turn out to be vulnerabilities.
Past experience suggests that when it comes to "local" exploitation, many
people involved in security do not necessarily draw clear boundaries
between bugs and vulnerabilities, at least as vulnerabilities have been
"classically" understood in the last couple decades. We occasoinally see
examples of this on oss-security. Multiply that by 1.2K and we may wind
up with some mayhem of our own.
There should be very clearly-specified reasons for why an issue crosses
privilege boundaries. If an attacker can only exploit an issue through a
command-line parameter, configuration file, or other input that must be
inherently trusted (otherwise the app can't function properly), then that
may not qualify as a vulnerability.
If the program is exploitable through input that could be untrusted in
common usage scenarios (e.g., "sort" may be executed on log file output as
in CVE-2013-0221), then that may be worthy of a CVE.
As far as I can see on the current Debian threads, some of the reported
issues do not actually cross privilege boundaries, and would therefore
fall more under the "bug" category than a vulnerability worthy of a CVE.
To fully understand which inputs or usage scenarios pose a real risk, it
may require a deep familiarity with the software itself - such as the
package maintainers.
Russ Allbery said:
>> I suspect you will not want to be doing CVEs for most of these.
>> The ones I've seen so far aren't really security issues. They're
>> cases of command-line programs crashing on input, but usually input
>> that is not feasibly under the control of an attacker (command-line
>> options provided by the user, etc.).
Hopefully this is the case. Perhaps we should rely more heavily on the
package maintainers to help determine this.
> Yup. hence the "Attack outcome (is this a security vulnerability in
> other words)". I'm hoping <10% of these are security vulnerabilities.
> But anything setuid/setgid, etc.... all sorts of potential for problems.
An issue in a setuid/setgid program still might not automatically be a
vulnerability - for example, if the issue is in a configuration file, or
if it only appears after privileges have been dropped, it might not be an
issue.
I was under the impression from an incomplete read of the MAYHEM paper
that it could generate shellcode for code execution, yet I'm only hearing
of reports for crashes. If code execution can be proven, then that may be
informative. However, if person X can already run code (like executing
the "vulnerable" program in the first place), and they can only introduce
shellcode through "trusted" inputs like configuration files, and the
shellcode will only run with the same privileges as X, then there is no
security gain and no privilege boundaries are crossed, thus not a
"vulnerability" in the classic sense and not worthy of a CVE.
- Steve
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
