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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ