Date: Fri, 08 Aug 2014 22:41:49 +0100 From: Eddie Chapman <eddie@...k.net> To: Greg KH <greg@...ah.com> CC: oss-security@...ts.openwall.com 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: > http://www.usb.org/developers/docs/devclass_docs/DFU_1.1.pdf > 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." ( http://arstechnica.com/security/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/?comments=1&post=27317503#comment-27317503 ) 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. Eddie >> 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.