oss-sec mailing list archives

Re: BadUSB discussion


From: Eddie Chapman <eddie () ehuk net>
Date: Fri, 08 Aug 2014 15:45:31 +0100

On 08/08/14 15:34, Greg KH wrote:
I don't understand what you are trying to solve here.  Step back, what
is the real "problem" that BadUSB shows?  Files being copied to places
they shouldn't be, or, rebooting your machine and booting from a
different media.  Why not go after the root cause here, don't be
paranoid about trying to detect a new keyboard being plugged in.

Again, we have had devices like this out there for quite a while, the
USB Rubber Ducky as one example.  Others are things like the Teensy
device[1], which has been used in "pen testing" for a very long time.

Don't try to defend against a random keyboard device, try to defend
against a user doing bad things, be it input from a "real" keyboard, or
a "fake" one, it shouldn't matter.

The only thing "new" about the BadUSB hack, is it shows how to turn a
"normal" device into a USB Rubber Ducky, which will save you a few
dollars (and shows just how insecure a number of USB devices are.)  Not
that the attack vector is somehow new and novel or unknown at all.

thanks,

greg k-h

[1] Highly recommended if you want to do things with USB from a device
side.  Easily programmable, very cheap, and very tiny, you can have
loads of "fun" with these things...

Greg, very relieved to see you involved in this thread. If anyone can speak authoritatively about Linux USB it's you.

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? Assuming you don't switch on a machine with USB devices already plugged in, 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?

Eddie


Current thread: