Date: Fri, 08 Aug 2014 15:45:31 +0100 From: Eddie Chapman <eddie@...k.net> To: oss-security@...ts.openwall.com, greg@...ah.com 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, 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 > >  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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ