Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 23 Aug 2016 15:32:08 -0400 (EDT)
Subject: Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices

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 ]
Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ