oss-sec mailing list archives
Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices
From: Ben Hutchings <ben () decadent org uk>
Date: Thu, 18 Aug 2016 17:43:50 +0100
On Thu, 2016-08-18 at 17:16 +0200, Marcus Meissner wrote:
On Thu, Aug 18, 2016 at 04:57:24PM +0200, Greg KH wrote:On Thu, Aug 18, 2016 at 04:39:57PM +0200, Marcus Meissner wrote:On Thu, Aug 18, 2016 at 04:30:14PM +0200, Greg KH wrote:On Thu, Aug 18, 2016 at 04:22:16PM +0200, Marcus Meissner wrote:Hi, I think this does not have a CVE yet, please assign. https://www.spinics.net/lists/linux-usb/msg144177.html Headline: Linux Kernel Panic Over USB with HID Keyboard wMaxPacketSize Platforms: Ubuntu Versions: Linux Kernel 4.4.0-22-genericHuh? It's much more pervasive than just that single platform or single version.That was the quote from the original e-mail. I read further on it affects more kernel versions.CVSS Score: 4.7 CVSS Vector: AV:L/AC:M/Au:N/C:N/I:N/A:C Filed Defects: Related Defects: CWE Tags: Cycle: Found by: Jake Lamberson Linux Kernel panics when using an OHCI controller if a USB device reports being a generic HID keyboard and reports a wMaxPacketSize of over 4095. The OHCI controller driver fails to reserve bandwidth for the device, causing the keyboard handler to fail when attaching to the HID. Later, when the device is removed, the system crashes due to a null pointer dereference in a linked list of endpoint descriptors. The crash can be re-created using a Facedancer and UMAP software. Given an appropriately configured Facedancer and UMAP setup, the crash can be re-created with: sudo board=facedancer21 python3 umap.py -P /dev/serial_device_here -f 03:00:00:E:0046 -l LOG Note: OHCI is a USB 1.1 controller standard that can be included with devices that support either USB 1.1 or 2.0 as their highest USB spec. USB 3.0 devices all use xHCI, which implements USB 1.1, 2.0, and 3.0, making them immune to this particular bug. ----------------- The proposed fixing patch is here: https://www.spinics.net/lists/linux-usb/msg144269.html It has not yet been committed to the USB tree or to Linus Tree as far as I see.Not true, it is commit id aed9d65ac3278d4febd8665bd7db59ef53e825fe in the usb tree and in linux-next and will be sent to Linus tomorrow.Ah sorry, only looked briefly.This was also asked about 2 hours ago on the linux-usb mailing list, why all of the sudden interest in something that we had been discussing for weeks now in public?No one asked for a CVE before. If that email request was from Oliver Neukum, he pinged me on it, so I started acting on it, so that explains this parallelism.And are we really assigning CVE numbers for when you use an active "hardware test probe"? If so, how many are people going to be assigning for these same problems on other operating systems? :)I think attaching malicious USB devices and crashing the kernel should probably get CVE ids, or do you think it should not?I don't know, that's why I'm asking, it requires "physical presence" which is much different from most threat models that people work to protect against.There has been quite a number of CVEs assigned to malicious USB devices this year already, this does not seem to be different. (e.g. CVE-2016-2384, CVE-2016-2188, CVE-2016-2187 etc.)
An attacker that has physical access to a USB port can short VCC to GND and likely destroy chips. If that is prevented by current limiting they can still destroy the port with glue or corrosive liquid. The possibility of crashing the OS is (usually) a much less serious DoS and doesn't seem to me to be worth worrying about. However, physical access to a USB port doesn't necessarily mean (easy) physical access to the rest of the machine. So vulnerabilities that allow a USB device to corrupt memory (such as CVE-2016-2384) can lead to a real privilege escalation and so are more concerning. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others.
Attachment:
signature.asc
Description: This is a digitally signed message part
Current thread:
- CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Marcus Meissner (Aug 18)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Greg KH (Aug 18)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Marcus Meissner (Aug 18)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Greg KH (Aug 18)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Marcus Meissner (Aug 18)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Ben Hutchings (Aug 18)
- Re: Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Adam Maris (Aug 18)
- Re: Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Willy Tarreau (Aug 18)
- Re: Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Marcus Meissner (Aug 22)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices cve-assign (Aug 22)
- Re: Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Greg KH (Aug 22)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices cve-assign (Aug 22)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Greg KH (Aug 23)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices cve-assign (Aug 23)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Marcus Meissner (Aug 18)
- Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Greg KH (Aug 18)
- Re: Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Willy Tarreau (Aug 22)
- Re: Re: CVE Request: Linux kernel crash of OHCI when plugging in malicious USB devices Kurt Seifried (Aug 23)