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 22:41:49 +0100
From: Eddie Chapman <>
To: Greg KH <>
Subject: Re: BadUSB discussion

On 08/08/14 20:46, Greg KH wrote:
> On Fri, Aug 08, 2014 at 06:40:50PM +0100, Eddie Chapman wrote:
>> Yes, immensely. It's clear to me now that being able to re-programme a USB
>> device firmware is not quite as easy and straightforward as is being made
>> out to be in certain quarters.
> On the contrary, it's trivial to do on a whole bunch of USB devices as
> that is how they were _designed_ to work.  So much so that there is a
> whole USB spec on exactly how to do this in a way that will work across
> all different operating systems:
> I don't remember when the 1.0 version of this spec was published, I
> think around 1995 or so.
> So I really don't see how this ability is anything "shocking" to anyone.

Yes, I knew about that, but what I meant was that, in practise, in the 
real world, for an attacker to achieve this in any sort of effective way 
across large numbers of targets is quite difficult. I found this comment 
from the ars article the OP linked an interesting argument:

"I can't believe we're this far into the comment chain and there's still 
a belief that simple USB devices with updateable firmware are anything 
but exceedingly rare, let alone common or the norm.

Yes, there's a DFU standard, but next to nobody implements it, and 
certainly the number of implementations for USB drives is vanishingly 
small. The margin for a thumb drive is basically zero already, and 
that's with small, cheap roms; why would any sane manufacturer add the 
cost of end-user modifiable firmware? At the factory, the rom gets 
written (and verified) on a burner and assembled later -- you'd have an 
expensive line for sure if you waited 'til after assembly to verify (let 
alone program) your firmware. Yield issues at the burner are cheap -- 
yield issues after assembly are not. Mass storage (and HID, for that 
matter) devices are well-known entities with fairly fixed 
implementations -- they just don't need updates, and the cost to enable 
them is prohibitive.

Now, a WiFi or 3G dongle or something else complex and dynamic could 
certainly be updated in the field (and many absolutely are), but thumb 
drives are not likely. Not impossible, of course, but unlikely.

Fixed-function is cheaper. Field upgrades are expensive. Thumb drive 
margins are razor-thin."


I don't know how much of what is said there is accurate, but it sounds 
plausible and makes sense. Without a survey of a large sample of devices 
I suppose we'll never know for sure what % implement the DFU standard, 
but I'd be willing to bet it is small.

Another person just a couple of comments later argues:

"Even in the cases where a drive is conceptually upgradeable, there's 
still the question of what the malicious payload would actually be, 
since there is a lot more variability in the embedded space in terms of 
chips and implementation than on the desktop. What's the MCU? 8051 (and 
pals)? ColdFire? Something from STMicro? Which instruction set? Memory 
map? Is there even room in the existing eeprom or flash for the 
composite device function (since it's the existing function plus the 
malicious new function)?"

I think that observation is probably accurate. Thus, it seems to me that 
criminals will look at this and conclude it is much easier and 
profitable to continue infecting machines in traditional ways.


>> That's not to say that the research being discussed hasn't thrown up
>> some very interesting issues around hardware and trust.
> Never trust hardware.  Until you have to.  :)
> greg 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.