[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 08 Aug 2014 16:47:45 +0100
From: Eddie Chapman <eddie@...k.net>
To: Greg KH <greg@...ah.com>
CC: oss-security@...ts.openwall.com
Subject: Re: BadUSB discussion
On 08/08/14 16:23, Greg KH wrote:
> 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? :)
He he, good point.
>> 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.
That's good to know. Not sure about the least of worries, the
overwriting of firmware seems to be the crux of what people are worried
about, isn't it? But I see your point, we don't need to worry since
you're saying firmware cannot be written unless it's initiated by the
kernel. But a lot of the discussion I've read on this issue seems to
assume that a "clean" USB device can have it's firmware replaced by the
bad guys with malware almost without the OS having a say in the matter.
e.g. USB stick with evil firmware infects USB controller, which in turn
infects other USB sticks subsequently plugged in. Although I've seen
people involved in USB hardware manufacture argue this is nowhere near
as easy as some of the hysteria surrounding this suggests.
But, theoretically, isn't it is possible for device and controller to do
their own thing between each other without the OS knowing anything?
After all, the OS controls the USB controller, but the controller is in
control of the device? Or does the kernel's control extend to the device?
Eddie
> 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.
