USB interface microcode may be inherently vulnerable
 

If Andy Greenberg and others are right, a large portion of existing USB devices - from keyboards to peripheral controllers and data-keys - may be vulnerable to reprogramming at the microcode level of the USB controller to do any and all kinds of nasty work that software viruses can do, and perhaps more.

In Why the Security of USB Is Fundamentally Broken Greenberg discloses some very new information about how ordinary USB devices can become high-power snoops and saboteurs with nothing more than some diddling of their internal microcode, loaded by a hacker into the device via the USB interface itself.

The effect of this discovery could be that no USB device may be considered totally trustworthy henceforth, whether memory or peripheral, if it remains internally reprogrammable at the microcode level after manufacture. Some USB-controller architectures have fuses or other locks that can be set to permanently inhibit reprogramming, but often these protections may not be engaged in existing products, observers say.

Seems to be a whole new can of worms to worry about. As of today!

Talk about stating the obvious !

If its running software (firmware and microcode being variants thereof) then there's possibilities for bugs, poor coding or just plain old overwriting .... all of which can be exploited by mischievous minds.

But quite frankly, you need to set a base level at which you trust things.... otherwise you just start behaving like a paranoid schizophrenic !

Its unlikely to come exploited out of the box, so its then up to you to not be stupid and click on stuff you shouldn't be clicking on and keeping your system fully patched and up to date (that includes any firmware updates for the hardware issued by the manufacturer !).

If Mr. Greenberg's assertions are correct, NONE of this is obvious. I cannot verify the whole chain in detail without considerable effort, but his case, as presented, makes sense. If it were easy to foresee this kind of problem, it wouldn't be a problem because many persons and enterprises would have acted to avoid or control the flaw. The relevant details for this prospective problem reside many dozen technical and conceptual levels below the window of ordinary user-knowledge and insight.

Your dismissive comment misses, misinterprets and trivializes the core problem identified and briefly described by Mr. Greenberg in the reference. Did you actually read it?

With fifty-odd years experience in computer architecture and design, going back a ways before the era of "microprocessors", I helped invent and patent the processes and methods of "microprogramming" which is a variant implementation methodology for the sub-instruction-level design of computing devices, deep inside the "cpu". The core architecture of a cpu, large or small, that uses "microprogramming" as an implementation method has the quality that the most basic machine-level "instructions" (op-codes) themselves are realized from a more basic specialized, superfast programmable engine wherein a sequence of "micro" instructions creates the component steps, behaviors, error recovery, etc for all possible states of each basic opcode instruction in the macro or micro-cpu by directly operating gates and states and latches and logical branches and "traps" that allow the process to occur precisely and efficiently.

Microprogramming, as described above, is very arcane and using it effectively requires a near-perfect knowledge and understanding of the exact electrical and logical sub-components of the core electronics, which may often change from one manufacturing batch to another. One way to decipher it, absent source data, is by painstaking observation and deciphering of the design by "peeling" a working chip and then observing electric fields (as insight to pulses and logic and architecture) on the chip surface during execution sequences with tools resembling electron- or AFM- microscopes. Doing this is normally beyond most hackers, and even most governments, but motivation can change outcomes.

More pernicious is the concept that most USB-interface products are built using chips from any of hundreds of manufacturers. Most of these have simple microprogrammable logic engines inside that are designed to provide design flexibility for implementing many products around a common core of functionality. Competing manufacturers often will use same or similar micro-engines, with proprietary code added, to implement both the USB function and other proprietary functions in the interface products they sell at dirt-cheap prices. Detailed engineering and microprogramming documentation is thus necessarily made available to hundreds or thousands of design and engineering people in a relatively uncontrolled manner. In many cases, it seems, the resulting end-user products are provided with means to access and modify their basic-device microprogramming over the USB interface -long after manufacturing - probably for updates, USB spec changes, etc, just by plugging device into a USB port with informed software controlling what follows.

..... And THAT means the core functioning of a very large portion of all USB devices potentially can be hacked to change their operational behavior such that a SINGLE insertion of a thus-hacked USB memory or peripheral into a computer system can permanently transfer seeds for subsequent complete takeover of the computer system - and all the things that connect to it by secondary means such as installed programs and interactive meddling over the internet. In the darkest plausible scenarios, a viral spread of the style and scope of this hypothetical hacking process follows, logically and asynchronously, from the first insertion of a virally prolific hacked USB device into a single promiscuous USB port.

Well that's a bit of a mouthful of a reply that I don't have time to compose a similarly lengthy reply to, however on a couple of issues :

Not really. As with many protocols and other interconnectivity in IT, security doesn't form part of the specification. Given the tight-margin and sales-led nature of the IT industry, as well as the requirement for interoperability, the majority of manufacturers do a minimum design to the specification and do not go into depth on security.

Do you know how much an in-depth EAL style security audit costs and how much work is involved ? When you're talking about cheap embedded components like USB there is not really much scope for that.

It is not a dismissive comment, it is realistic. If something involves the running of firmware, microcode or whatever you want to call it, then there are inherently possibilities for exploitation. Its simply a case of not if but when !

Unless you go all the way up to EAL7 where an obsessively rigorous formal design methodology is required, there are always going to be risks.

Which is why only utter morons plug an untrusted USB into a computer. ;)

There is an old saying in IT security .... once the attacker has physical access to the computer/server/laptop/whatever device then it's game over !

This USB scare is really not much different than the Windows autorun virus debacle of a few years back !

so you helped to create the problem by not making a secure system.

I think I'll wait until this "proof-of-concept" has been shown to work reproducibly and significantly in the real world before I start panicking.

Anything that has embedded firmware; your mobo, your printer, your bluetooth dongle, your router or network switch is theoretically vulnerable to tampering.

As any fule kno.

Mac

:cool:

It's a nasty problem if the firmware had been tampered. If they can do it to a USB then SD card firmware can be tampered also. How about the hardware based encrypted USB, will they have the same threat? There are some USB who have the encryption keyed to a chip which cannot be passed to a memory or never passed on the USB or system bus.