Apparently, the article gushes, you can create corrupt USB firmware that will infect any computer it is placed it! In turn, any USB drives leaving that computer will also be infected!
First of all, what exactly is flash drive firmware doing executing on the host machine? USB’s just a 4 pin connector with 2 data and 2 power. I would have assumed it was just a communication format, and each flash drive has it’s own small processor or microcontroller that interprets signals coming from the communication pins and translates them into commands for disk access.
Some of the steps for accessing flash memory chips at a low level must be extremely complex : there’s wear leveling as well as the actual timing for accessing each individual part.
It sounds to me like what is happening here is the moment the USB drive is connected, the host OS is given some kind of executable file that runs at the driver layer. I’m guessing this file contains code that presents the flash media as an actual disk with all the high level interface that windows is expecting and handles the calculations for wear leveling and so forth.
The problem here is if this is true, how do you access flash drives on Linux or ARM? If a flash drive really is permitted to run native machine code on an x86 machine, it wouldn’t be possible to even access one on a different architecture.
The second problem is that the “firmware” is allowed full privileges? It’s permitted to access any memory, write to the disk, do anything? A logical approach to implementation would be to sandbox the firmware and prevent it from accessing any memory but it’s own and any hardware other than the USB port from which it originated. I take it that Windows doesn’t have this kind of protection?
Consider all the things you can do with USB. It’s not just for storage: You can plug in a keyboard and mouse via USB, too. Which means that you could in principle (for instance) make a device that externally looks like a thumb drive, but which acts like a mouse and keyboard when you plug it in and starts typing in commands. Now, that could certainly be done with hardware… With software? I dunno.
The most obvious host vulnerability is autorun. That’s kind of old-fashioned, but technically still possible if that hasn’t been disabled or configured out of the host OS. (Think old, unpatched OS on an internal network… unpatched because “we can’t get to the internet, so we’re safe, and our legacy application can’t tolerate OS upgrades.” The most prominent theory I’ve heard about Stuxnet getting into various industrial-control networks was that vector.)
The Evil HID angle (Human Interface Device, like keyboard) is I guess another exotic one. This would have to be tailored rather carefully against the host target, since what you “type” to pwn a machine would depend on the machine. I rather doubt a USB peripheral’s access to the host would be enough to much serious probing/target characterization, but maybe it’s possible, which would make such an attack less platform-sensitive.
And I’ve heard of some historical speculation about taking advantage of organic weaknesses in USB drivers to do attacks similar to network attacks for the purposes of getting the host to execute arbitrary code (provided by the evil device) in the security priviledge context of the device driver. Things like buffer overruns or stack smashes.
This last category is, I think, the one you’re asking about. One problem in sandboxing device drivers is performance. In both Windows and Linux, device drivers run in kernel memory space and with kernel priviledges, largely because context switching and message passing between a userspace driver and the rest of the kernel (which hosts the functions above the driver level) can slow down using the device.
Does this mean what I think it means? For example, you could write a driver that ordered a particular core windows file to be replaced with an alternate one, and it would also update whatever file integrity hash Windows stores to reflect the new file being uncorrupted.
I take it that at this level, the disk accesses would happen with nothing to challenge it.
That would let you pwn the machine permanently, and the new file would run code that would insert this virus into the firmware of any of a wide class of flash drives that are plugged in to the machine.
The device can’t replace its own driver. But a driver already in the system is trusted with the memory access and priviledges of the kernel, and if it contains an exploitable vulnerability, its access and permissions can be potentially used to make arbitrary modifications to, as you put it, “pwn the machine permanently”.
Its all exaggeration. There is nothing new here. Its just as dangerous as a floppy disk or a web page or email… its a file from somewhere else… it could be a virus.
If I don’t run the program there, then I am not running the virus.
No matter what sort of virus in the USB’s firmware, my computer will just get data and handle it… My computer should only treat the files there as code…
Perhaps the OS should say "Hey, you are running an executable from USB -thats really dangerous,are you sure ?? "
If my software as a flaw, such as a buffer overflow weakness, then that can be exploited no matter how the file gets to me. If my picture viewer software has a buffer overflow weakness, then thats the flaw right there.
What would be dangerous would be if the USB drive was merely memory mapped into the host’s memory range,and the USB device got to set the memory location.
Then the USB device could always push its code to be at a location where my computer could run it… BUT NO, USB does not get to set the memory address for the data to be read from … the host computer sets that address, its all safe
(DMA makes the data memory mapped. but sets the address… perhaps the authors of the scare mongering article think that DMA system is controlled by the USB peripheral chip ??)
If the DMA allocations in the driver are careless, you’re looking at a possible buffer overrun. Likewise if the device insists on PIO mode and smashes the allocated buffer because of inadequate bounds checking.
Ample evidence that these kinds of buffer overruns occur in USB device drivers. The only question remaining is “how many of these are exploitable for more than a BSOD denial of service?”
This is both, not new, and a very real risk. It has nothing to do with files on a USB stick, attacks on the operating system directly, or indeed that much to do with the OS operation at all in the first instance.
The issue is this. USB devices and USB controllers are now sufficiently complex that they are small computers in their own right. The USB protocol is pretty simple, and sadly many interface devices assume that everyone plays fair - and doesn’t abuse the protocol. But there are issues - as there always are. So - you can reprogram the controller on a USB flash drive with new firmware, and have it attack the program running inside the USB controller chip on a computer. So far this has nothing to do with files on the flash drive - and nothing to do with the device driver software in the host operating system. The aim is not to own the OS, but to own the USB controller chip. From here you want to bootstrap your way into being able attack the OS. The really evil issue, is that the attacked device may be permanently owned, in a manner that is invisible to the host OS. Hard for a simple interface device, but any device that has internal non-volatile memory is at risk. Devices that can be field upgraded with new firmware are totally subvert-able.
Such exploits have been done in the past - usually to more advanced interface devices. WiFi controllers are a good one. There are exploits that allow a laptop’s WiFi interface chip to be owned via the radio interface. The chip can be subverted even whilst the host operating system is still using it.
The really open interface systems are things like Firewire and Thunderbolt - as these provide open access directly to system memory. But these device controller exploits are much more sneaky. They are of course specific to a particular controller chip - but when you go into it, there are very few individual designs - they often just get copied time and time again into new chipsets.
This was listed as a potential threat at least five years ago. I remember an article by a security tester that said the best and most dependable way to get spyware onto a computer was a “USB drop” – just leave an infected USB drive where someone is bound to find it. They will then put it in their computer to see what’s on it, and you can infect them that way.
It seems a lot of posters didn’t read the linked article. This isn’t about autorun and has NOTHING to do with the files stored on the device. This is a corruption of the firmware inside the drive. The firmware manages reads and writes to the drive (spreading operations evenly across the cells*, prefetching, error correction, etc.) and identifies the device to the OS (thus determining which drivers** the OS will load, and what functionality** it can access).
It’s very much akin to a infecting the BIOS.
*so cells wear out evenly. flash memory cells have a finite number of write operations before they become unreadable (0 and 1 become closer with each write until they’re indistinguishable)
** from the choices that the OS offers. It can’t currently install it’s own drivers, but it could cause an insecure one to be loaded, or request functionality the user doesn’t expect (e.g. network interface, keyboard, even a monitor/display)