Slashdot Mirror
System Exploitable With USB
Anonymous Coward writes "Vulnerabilities in USB drivers for Windows could allow an attacker to take control of locked workstations using a specially programmed Universal Serial Bus device." From the article: "The buffer-overflow flaw is in device drivers that Windows loads whenever USB devices are inserted into computers running Windows 32-bit operating systems, including Windows XP and Windows 2000, said Caleb Sima, chief technology officer and founder of SPI Dynamics."
Computers with physical access are susceptible to "unintended root-level access".
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
This is similar to an early security flaw in windows though I forget precisely which Windows versions it was, 95 and earlier I suspect. It was possible to write a program that would autorun from an inserted CD and copy the screen saver password file to a floppy from where it could be later cracked at leisure.
From the summary and the article:
Vulnerabilities in USB drivers for Windows...The buffer-overflow flaw is in device drivers that Windows loads...running Windows 32-bit operating systems, including Windows XP and Windows 2000...
The article then goes on to say:
However, the flaw is with USB, not Windows, said David Dewey, a research engineer at SPI.
'plug and play' hacking .....
Flaws found in device drivers shipped with Windows, Microsoft recommends upgrading to Vista!
"What would be funny is if Vista had this bug when it shipped..." Hey there, this is microsoft, in order for us to not get sued we need you to use "Windows" in cojuction with the word "Vista". So please kindly edit your post, you wouldnt want us to get sued, would you? darling? sweety?
Oddly enough, this isn't a particularly new idea. The Xbox Linux project considered the possibility of using a specially-designed USB device to run code on the Xbox, though I don't think they managed to find a suitable vunerability to exploit (unlike now). I wonder if this works for the Xbox, actually - it's Windows 2000 based IIRC...
Sadly enough it is not at all suprising that Slashdot immediately goes for the anti-Windows slant rather than actually reading and comprehending the article and exploit in question. Too few actual axploits in Windows as of late to get up to the required quota perhaps?
In a more direct comment about the "exploit" I don't consider it terribly important, hardware access leads to a lot of trivial expoits. This one can be made more user-friendly than most with appropriate hardware, but it is not really worse than just inserting a boot CD that copies the relevant data to a secure server or so. It can also of course easily be fixed by disallowing loading of USB drivers without confirmation from the user.
USB flash drives are already quite highly accepted amongst non-technical users; both my parents have bought pendrives, as have many of my friends. They're quite comfortable with just popping in the drive, waiting for the OS to see it, and grabbing files off it.
So, what if someone handed them a pendrive and asked them to grab some files from it, and it turns out that this pendrive would cause an attack like this? One could be switched by a black-hat, or planted, or mailed... put simply, the attacker wouldn't need physical access, just access to someone who does.
And tomorrow the stock exchange will be the human race
This reminds me of the vulnerabilities discovered in linux (and other systems) concerning firewire; Since Firewire devices can read and write directly to the computers memory, you can do some nasty stuff. The issues are documented on the website of the german CCC: http://www.ccc.de/congress/2004/fahrplan/event/14. de.html
Life is just nature's way of keeping meat fresh.
How about this: I lend my usb key to you so that you can transfer a file. While connected to your system the usb device cracks the security on your windows box and grabs the information I was looking for.
I don't need access to your system for that to work. I don't even have to know where it is. I have a usb key/mp3 player device which will let me reflash the firmware, so perhaps I could put the exploit in that way.
http://michaelsmith.id.au
Given enough time and resources, I have physical access to anything. If your computer is in a locked case, is that physically secure? In a lab that is always staffed? Behind a locked door? With a guard?
For many situations, a computer with a locked case in a room that is staffed is considered "physically secure", as it's not likely that you'll break the physical security (lock on the case) without attracting the attention of the staff. Hell, even a computer in a staffed room in a case that has screws on it is fairly physically secure. The USB problem circumvents the physical security.
Security is all about deterrent. My apartment has a dead bolt lock on the door. Does this mean it's impossible to break into my apartment? Of course not - it just makes it harder.
Being able to break security on a locked computer with a USB drive is like leaving the key to your apartment under your door mat.
paintball
From TFA:
So how can it be in all usb drivers?
http://michaelsmith.id.au
I really wouldn't give these guys the publicity at this point.
They haven't explained what the problem really is, to us, or even filed a report with Microsoft.
They also claim that any OS is vulnerable, though it's only been tested with Windows drivers.
The whole thing just stinks of someone wanting publicity or setting up to try to sell some protection software.
How did this get modded insightful? Obviously you AND the mods did not read the article and have absolutely no idea what's going on here.
First of all there is only one USB subsystem driver for Windows. That's not actually technically correct since there are drivers for the various USB control architectures (such as UHCI, OHCI, EHCI), but they use are a small part of a larger unified USB subsystem driver.
I suspect you mistakenly thought the article was talking about the individual usb device drivers (for things like gamepads, cameras, printers, etc).
This is not what's happening at all. This is a Windows vulnerability, and actually has absolutely nothing to do with USB, other than it affects the USB subystem of the Windows (and only Windows) operating system.
There's a buffer overflow in the USB system, which allows any properly designed device to be plugged into a locked Windows computer, and execute arbitrary code (ie unlock the machine, etc).
You may think this isn't a big deal, but this is a huge deal. You can pick up USB dev kits for a couple hundred bucks that come with an FPGA, flash rom, and more. Basically for the price of one of these devices you could theoretically walk into any place where you can gain physical access to a Windows machine, and pwn it.
The problem is that we do not have a modern operating system architecture that is fast enough to allow for drivers to run in another privilege level. Seen the wonderful server performance of OSX? That's what happens when you put drivers at a different privilege level than the kernel. The real issue is twofold. Firstly, context switches are extremely slow, even on modern processors. In the IA-32 architecture, which has three privilege levels, most microkernels have put kernel code at ring 0 (most privileged), drivers at ring 1, and user code in ring 2. But what you end up with is every system call going from user -> driver -> kernel -> driver -> user. This greatly slows down the system, especially in a uniprocessor multitasking operating system. Things get even more complicated when you're trying to write a portable operating system (Linux/*BSD/NT Kernel), since most other chip architectures only offer two privilege levels (user & supervisor).
I guess my point is simply that we've tried this isolation you speak of, but it truly offers horrendous performance, especially graphics subsystems. Take a look at some of the research on Mach, why no one uses it (well, except Apple). Check out Jochen Leudtke's research on the L4Ka microkernel, and how they've gotten near monolithic type speed out of a microkernel by caching calls between privilege levels to minimize context switching.
OS Development is fun! It also allows you to look at the common (and not so common) operating systems in a whole new light. And don't get me started on the Linux kernel. Until the 2.4 series, I could have done better with 6 months and an unlimited supply of pizza and Sun Drop (and no, I can't get the good Sun Drop where I live!!)
So in short, every modern operating system (sans OSX) runs drivers in Kernel mode. It's a necessary evil. Maybe one day, the speed decline will be negligible, but as long as context switches take over 1,000 cycles, and as long as you can trigger tens of thousands of context switches relatively easily in user/driver/system interactions, with very few user-level instructions (i.e. libc), we'll always have this problem.