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

> 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
  http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJXu4LCAAoJEHb/MwWLVhi25yAQAIpHJGpnkiVI8osth0zpuGNJ
RwNEne6YpaP0evP3Rj8RahQ8qMB0lEQPnH0sHliuRT5rUsZx40IEsHNoOOg8s5EE
vKxuYU/lhrYsWPqYTkjKJjxvuLO2dARzytDkLCyK69snQzEBYY8i7YTlI/Q2+1Fd
qKy0RlbJdrdGzjIuR+j3zovMna3qFIsnWPl0uVi5RQCM8S6AJy6KTCeSYurncsqu
KDIjvWIWMavV5mTzy1RevSShB6StnP/F8MeUqIUF3xbIAfGOqG51mr7XnUYOEIPM
U0imdTupQgJ4wJjYs7Q0RiSSUrlbLHWD+s7URoqez5rqMgbBc1ugq1uBlo5DBHWk
uwEwn4mwVrMXu9k04yY8FyplntQDkDULKCCC1hsiExMO5gBhCDYi9CbYrTszP8NF
q/ynMDJxOY5GmFPD5fafmKUKa3G+KXRt7MpU+LNfH5c7KiOcNOt7Igon2NI2RqOA
HxliE2ZhB4kkf/qD+wqbVC0ZQegXnnKiIOEvFqUY2FpHOLvZ0A+EuIlGjy+N8zLW
Eji1Imq6wr+p95eXzvp5w2fVVydujDQD/xI2p3isb7Tv640s4plC22rjMVPd0zbz
hE6g97Q2gSzCsBnC3ZlF30PVeLw2vErlnFoBqy6IRgBRBNQCzv94SRy9DUNICKX+
fhdbnuRUSLsHmqtLmH7+
=fXqf
-----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.