Date: Fri, 8 Aug 2014 08:23:31 -0700 From: Greg KH <greg@...ah.com> To: Eddie Chapman <eddie@...k.net> Cc: oss-security@...ts.openwall.com Subject: Re: BadUSB discussion On Fri, Aug 08, 2014 at 03:45:31PM +0100, Eddie Chapman wrote: > The main question in my mind, and what I see as the main issue, is once the > kernel has booted, how much can USB devices get up to, if anything, behind > the kernel's back? "behind"? Hopefully nothing, but as been proven in the past, bugs happen and there are things that can go wrong. Look at the raft of USB HID (input devices) bugfixes that happened a while ago to fix buffer overflow issues that had been found (and were being exploited for years it turned out.) There are a lot of USB drivers in the kernel, doing some good fuzz-testing of them with a USB device that can do that would be great for people to do to verify that we have caught all of these types of bugs. > Assuming you don't switch on a machine with USB devices already > plugged in, Like a laptop with built-in USB devices? :) > assuming your motherboard's USB controller chip hasn't > been doctored by the manufacturer/government/whoever, and assuming you plug > a device (not a hub) directly into a motherboard USB port, how much > *significant* interaction between device and USB controller goes on that > could not be seen, even with the right debug settings enabled? i.e. could a > clean device really have something as (presumably complicated) as its > firmware being overwritten without the kernel knowing and potentially > alerting about it? Firmware can't be sent to a device unless it is enumerated by the kernel USB subsystem, and that is usually visable to the kernel by default. Sending firmware to a device is the least of your worries, see above for the real problems that you can try to exploit. Testing the USB stack with "invalid" configuration descriptors is a great place to start. Hopefully we have fixed all of these issues, but no one is guaranteeing anything... Sorry I can't make you feel better, at least you can't do DMA directly to/from USB devices, so that attack vector is not there, unlike Firewire and PCIe. greg k-h
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.