Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 08 Aug 2014 15:45:31 +0100
From: Eddie Chapman <>
Subject: Re: BadUSB discussion

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?


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.