|
Message-Id: <20160823193208.DB3356CC2D3@smtpvmsrv1.mitre.org> Date: Tue, 23 Aug 2016 15:32:08 -0400 (EDT) From: cve-assign@...re.org To: greg@...ah.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, meissner@...e.de Subject: Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We're unsure whether all of your remaining questions are within the scope of the oss-security list. Some of them seem to be questions about CVE in general. We don't see much demand for CVE to be the mechanism by which people can make 100% of their decisions about whether to connect an arbitrary USB device. > Are you really saying that you need authorship permission here in order > to create a CVE? If the author agrees that a CVE ID should exist, then that is typically sufficient (but typically not necessary) for CVE ID assignment. We don't think it is realistic to try to document every corner case here. For example, maybe an author agrees that a CVE ID should exist only because they have a totally incorrect understanding of what CVE is (e.g., they ask for a CVE ID for the mistake of releasing their code under the wrong license, and we refuse). As far as we know, people aren't abusing the authorship role to try to arrange for their own code to have as many CVEs as possible. > Ok, but then why is this somehow CVE related if a Linux system can "not > handle" such a device? An author could write userspace code that contains some type of logic or algorithm to determine whether to tell the kernel to use a USB device. Then, the author could decide that this logic or algorithm was wrong, and represented an exploitable vulnerability because it offered an attack mechanism that the author had not intended to offer. Finally, the author could ask for and obtain a CVE ID for their own vulnerable userspace code. > So if an operating system were to not trust new USB > devices, it could then probably not be USB compliant. We don't know to what extent userspace code is part of the "operating system." However, in the above scenario, the author could assert that their own userspace code was vulnerable, because they specifically wanted their userspace code to violate the USB specification by providing less "trust" than the specification requires. > Are you going to start filing CVEs against hardware specifications? We probably don't have CVEs yet for hardware specifications, although we did have one CVE (CVE-2016-2427) for a specification that could conceivably have a hardware implementation. > So how could this ever be something that an operating system > could implement? "pops up a dialog asking about each new USB device" could be implemented, and might prevent a malicious-keyboard attack some of the time, but it's a poor solution. So, if a random person picks one of the many real-life operating systems that don't pop up these dialogs, and wants a CVE ID to track the status of adding that poor solution, then we won't provide a CVE ID. If someone is the author of a hypothetical single-user operating system where this solution works and is requiring all of their customers to take a security update to version 1.1 with this solution, then they can have a CVE ID for the vulnerability in their version 1.0. We'll leave it at that. This list is about open-source software, not hypothetical software that will probably never exist. > In summary, yes, this is a mess where the physical world hits the > software world, and unless you all draw a _very_ clear line, this is > only going to get worse and worse. Yes, the line will be drawn, but iteratively. We do generally agree with Willy's principle that "something where a bug allows someone unauthorized to do something he couldn't do differently needs a CVE." We also think that the author often has the clearest picture of whether "something he couldn't do differently" is actually true, and thus we feel that the author's perspective matters. We just don't believe that we can proactively identify every corner case. - -- CVE Assignment Team M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [ A PGP key is available for encrypted communications at http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJXvKRCAAoJEHb/MwWLVhi2gPMP/R3kM1v3OeBEReKpGJSOxSJ0 b3vHHscLpYmSbE+KgnYvG5pacSjj77b85HZ+iY3VLpRWSO4G9lD5yOqM2I95etJs 2mU1CzXXUxpDYwPsDFnt7BRovL/4CVuUSaPe1C2fBdjLGkNxcxGwCkO+9BFDEoEj JvS65bXoG0sD+/AXBUIPs5j02Ul2Fx79/ByqfIbB02m2/LQLmrw6W3jbdLGn1ptT XYM9QiRjP5lvSe4t1wkvyM+Tke6iJHUQLpT00t0bW3NbV1DHFze3DKbAPo2KOTCU odLZL/Gd6EejzDgdj7it7skaDwX1FUNyRmO+wF2H3oppGRkTbuzN0ZNpFoJfXoZ4 OR2tucLnsgGgBkDhxQDDTcahfbhjqk19gZBQIywEb1F3zj8Hpx4p4671YHlKh6l1 H1EgF2ZYXcEr/054PmGdPUU7m8PyiFjVnlCBwu4p16B7HzxvJMzSTdDZR4rQe6wm R4mGLHa/kJIJrHRsNOuCWxc2fA+i4rWp6otDDoETyCYqVBKaTqtjRj3wRxAr2hj5 5U6UTi3uGpzmwjjcitemckh/mg8M3FGgx9L5Z0NSSAgLsknxygm9YDS/OPrS/wOM Sq0ZQ7KqKIwHJ9i2vMlRfr/X3INYyRaIOSF34WQ5KE1BmvI6V9Tsnqa5ciTvo949 QdAJvnGjGDYMIqVXixXJ =HAsi -----END PGP SIGNATURE-----
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.