Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 22 Aug 2016 18:57:53 -0400 (EDT)
Subject: Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices

Hash: SHA256

> 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.

>>    - 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.

>>     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. 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."

>>   - 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. 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.

- -- 
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

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.