[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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[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
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.
