Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices

[Greg KH <greg () kroah com>]

On Mon, Aug 22, 2016 at 06:57:53PM -0400, cve-assign () mitre org wrote:
> > What "tool" was assigned this CVE for other operating systems
> > that do the same thing (all BSDs, OS-X, Windows, etc.)?
>
> We didn't find any information about a tool name and thus simply
> listed the OS itself (CVE-2011-0638, CVE-2011-0639).
>
>
> > >   - the Linux kernel does not require a configuration in which a newly
> > >     connected USB device is recognized in any way
>
> > I don't understand this statement, can you clarify?
>
> To clarify: the ability of an attacker to connect a USB device and
> trigger potentially unsafe device communication (e.g., injecting text
> into an application) does not mean that the Linux kernel is missing an
> access-control feature.

Ok, but then why is this somehow CVE related if a Linux system can "not
handle" such a device?

> > >    - a Linux distribution may ship with a default configuration in
> > >      which a newly connected USB device can operate as a keyboard and
> > >      inject text into an application
>
> > Yes, but I don't understand, perhaps what you really mean to say is:
> >        A Linux distribution may ship with a default configuration of
> >        trusting all new devices that are plugged in without any form of
> >        userspace authentication before they begin to operate.
>
> Agreed. If it is trusting all new devices in this way, it would also
> be trusting all new devices that wish to operate as keyboards.

So can you agree that the USB specification requires the OS to trust all
new devices (it only requires "authorized" functionality for wireless
USB devices.)  So if an operating system were to not trust new USB
devices, it could then probably not be USB compliant.

Are you going to start filing CVEs against hardware specifications?
(personally, I would love that...)

> > >     there is no comprehensive method
> > >     for "asking a user" about a new USB device in a way that is
> > >     compatible with all use cases
>
> > Huh?
>
> A Linux distribution cannot expect that there is a logged-in user who
> can provide sane answers to questions about each new USB device at the
> instant that that device is connected.

No multi-user operating system can.

> For example, there isn't a comprehensive solution of the form "a
> distribution must ensure that an application pops up a dialog asking
> about each new device."

I agree.  So how could this ever be something that an operating system
could implement?

> > >   - if anyone (whether a Linux distribution or other type of product)
> > >     is announcing a required security update, in which software or
> > >     configuration is being changed to address malicious keyboard
> > >     attacks, then we can assign a CVE ID to associate with the update
> > >     announcement
>
> > Why would a CVE be needed for a "my distro decides to not trust USB
> > devices as much as your distro does" type decision?
>
> To improve the usability of CVE for patch management, we allow a CVE
> mapping for an issue where the author of the code has announced a
> required security patch, even if the issue is not universally
> recognized as an exploitable vulnerability.

Ok, but you are not doing this for where the "author of the code" is
saying this.  If so, you need to go delete a bunch of Linux CVEs, as I
sure as heck didn't want them created for my code :)

Are you really saying that you need authorship permission here in order
to create a CVE?  That seems new to me...

> This can be helpful in situations where a vendor has direct knowledge
> of advertised use cases or customer expectations. For example, if
> there's a Linux distro designed specifically for connecting
> compromised mobile phones over USB and initiating forensic analysis,
> then it's perhaps reasonable to say that unrestricted acceptance of
> new USB keyboards is a CVE-worthy vulnerability for that one distro.

But given that we know of no such distro, why are you all creating new
CVEs for these types of things?

And, like Willy keeps pointing out, it's easy to break the hardware with
USB with a bad devices.  I accidentally purchased such a thing in Japan
a few months ago, and now am no longer able to use one of the USB ports
in my laptop as the "magic smoke" escaped from it when the device was
plugged in.  If we could get a CVE issued for that hardware design
fault, that would be great :)

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.

good luck!

greg k-h