Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Aug 2014 09:17:22 -0700
From: Greg KH <>
To: Eddie Chapman <>
Subject: Re: BadUSB discussion

On Fri, Aug 08, 2014 at 04:47:45PM +0100, Eddie Chapman wrote:
> >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?

I don't know, is that something that people really care about?  And if
so, why?  What can you do with a device that you can rewrite the
firmware to that you can't do with any other USB device that you are
intentionally making "malicious"?  (i.e. USB Rubber Ducky and friends)

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

Or userspace, but the kernel is involved here in sending the data to the
device, it has to.

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

Not true, the OS has to be involved in order to rewrite the firmware.
It is the thing that is sending the "bad" packets to the USB device on
behalf of the userspace program that is asking to rewrite the firmware
on the device.

> e.g. USB stick with evil firmware infects USB controller,

The USB host controller, no, that's not possible that I have ever heard
of, or seen before.  But pointers to the details would be appreciated if
somehow you think this is the case.

> which in turn infects other USB sticks subsequently plugged in.

Unless the program to rewrite other USB devices was downloaded and run
from the "evil" device, no, the OS knows all about this.

Now if the OS can actually do anything about it or not is a different
story, again, if you allow user space programs the ability to write to
random USB devices, well, you get what you deserve here...

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

There is a USB firmware download spec, which is quite easy to use, if
manufacturers actually followed it (side note, I was one of the authors
of that spec...)  And if USB device manufacturers actually required
signed firmware to run in their devices, that would solve this issue
instantly as long as the signing keys don't leak.

> But, theoretically, isn't it is possible for device and controller to do
> their own thing between each other without the OS knowing anything?

There are some "basic" housekeeping functions that the USB host
controller and device do in their handshaking and keep-alive and the
like that the OS doesn't "know" about, because if the OS did know about
it, the whole thing would just take too long and waste too much CPU
time.  But sending random data?  No that's not possible.

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

Think of a USB host controller as a "dumb" ethernet controller.  It has
a big ring-buffer of data that it sends to a device when asked to.  It
also listens for data from a device, when asked, and puts that in a
buffer for the kernel to do something with.  There is no "mixing" of the
data, and a USB device can not talk to any other USB device on the
system, without the kernel giving the data to the other device.

So the kernel "controls" a device only by sending it data, receiving
data from it, and by virtue of some of that data being "special",
telling the device to do some things (send configuration information, go
toggle a serial port pin, etc.)  That data can only come from the
kernel, to the USB host controller, and then to the device.

Again, over simplification, as there are some commands that the host
controller handles on its own by virtue of "housekeeping" and
enumeration, and other basic things, none of which should ever be an
attack vector to the device, unless you have a really broken device.

Does that help?

greg "usb-101 is now over" 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.