[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
