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.