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.
Really, how serious a threat is this? If someone has unrestricted physical access to your machine then you're already in serious trouble. We all know how breakable the NTFS file encryption is, so if they really want to get at your files, they can just reboot into Fedora from a CD, or run any other tool that circumvents the encryption. If they just want to destroy data then you can put a hammer through the hard drive, and no OS can prevent that... So, I'm not saying that this vulnerability shouldn't be fixed, but maybe they should work on making NTFS a bit stronger first - if that's even possible.
Also, does anyone else think Slashdot should have a special section for buffer overflows? They seem to spawn more stories than several of the other sections...
apterous.org
'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 come these things still happen? Lazy programmers? Crappy x86 archtecture? These self-created problems should still be around.
...and that is all I have to say about that.
http://jessta.id.au
A bios option to diable USB would be nice. especially in an enviroment that doesn't need USB for anything.
A lot of systems do not have the option.
Who run Barter Town?
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
If the problem truly lies in the USB standard, wouldn't other operating systems that implement USB also be affected? "multi latform exploit" ... kinda makes you just wanna drop your other projects and get to coding that proof of concept doesn't it?
Really, how serious a threat is this? If someone has unrestricted physical access to your machine then you're already in serious trouble.
Surprise, it's just a little more sensationalism at eWeek. If this weren't somehow related to Microsoft Windows, then it might not have been given a front page reference here at Slashdot. Corporate espionage and cyberterrorism, oh my!
Perhaps it's intended to evoke an image of a man standing at a workstation and inserting a USB device that automatically captures all of the corporate trade secrets. It's only going to frighten those who are uninformed, as you've effectively described the entire problem. Unless the organization in charge has established an extremely secure physical environment, then their sensitive information will always be susceptible to physical espionage.
If their only layer of protection is provided by a locked Windows workstation, then a network-based attack might prove itself both less expensive and more effective, anyway.
Do you like German cars?
From TFA:
So how can it be in all usb drivers?
http://michaelsmith.id.au
So you could hack up USB device (e.g. a flash), send it to a company, and kaboom.
Or leave a few lying around at Starbucks (like the exploding toy-like objects the Soviets dropped on Afghanistan).
http://www.thebricktestament.com/the_law/when_to_
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.
Ive known that most any system that can boot from usb was vulnerable for at least a year now. I keep DSL on my thumbdrive and need to get it onto my ipod shuffle now too.
Scott Swezey
And, of course, any interface that allows unrestricted DMA (PCI/Cardbus, possibly Firewire) will be impossible to guard against, no matter what OS is in use.
If you get close enough to plug in a USB device, you're close enough to boot it to a crack CD and a) wipe the system b) blank the admin password c) take all the data (and copy it to a USB device.
It seems obvious that this can affect any OS, and is due to the poor design of USB- If a device posts a number, then the system assumes it's such-and-such, and loads the driver. Which probably has bugs. So, how do We (that is Open Source system developers) deal with this?
Of course 1. is to make sure that all drivers in our trees have no overflow bugs. Or any others, or course. This takes work, but we now know that it is needed. You cannot trust any info that a USB device gives us. Shoulda known.
Of course, some painful hardware vendors will _insist_ on providing only binary drivers. Am I alone in thinking that running these as root, melding thrse with no less than the system kernel, is unacceptable? So a fast, secure universal usb interface is needed. I know I have ugen in FreeBSD, and I hope it's secure, but is it fast enough for pedantic hardware vendors? What's the linux situation look like? As you are the ones that have been provided with binary USB drivers, what do these look like?
And, no, i do not like the idea of running any binary only code. But at least we need to sandbox it off, and reduce it's permissions.
So, what does everyone think can be done?
Prediction for end of Universe #42: Fencepost error in Quantum_bogosort.cpp
On the other hand, I would quite mad if I had to confirm that my new keyboard and mouse should, in fact, be used. (Catch 22, hey?) Only allow plug-and-pray of anything but a very limited set of devices (user configurable?) from anything but Administrator. That would solve most of it.
I wonder when people will start poking more at Nvidia's and ATI's OpenGL drivers on all platforms. That should prove interesting, especially since the binary drivers may actually contain the same flaws on several platforms.
First and foremost, the guy says he has NOT notified Microsoft, but then goes on later to say:
"I was really looking to them to address this issue, but Microsoft feels that this is a hardware issue and doesn't see it as a problem," he said.
Which one is it, you told them or you didnt?
Then he goes really REALLY far out of his way not to mention which driver is supposedly exploitable... is it a driver HE wrote?!
I'm giving this 95% that its a driver HE wrote and installed to exploit ring 0 access, not an exploit in the existing usb stack components, which makes the whole article a self serving lie.
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.
No, you are wrong. Specific USB device drivers is what the article is all about.
They even mention this:
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.
This is just a report about the general issue that all USB drivers have to be secure or a hardware device can be made to exploit the machine.
There's many specifications (IPV4 springs to mind) that weren't designed with security in mind. It's the responsibility of the OS writers to design their OS to handle such insecurities. There's nothing in the USB specs that say that the OS must run the USB driver at ring 0.
It is in no way about Windows, but actually about any operating system than implements USB.
The article gives two specific cases:
1. The ability to unlock locked systems (say, while the user is at lunch). This gives far more than just owning a system physically. You now have access to all of their network priviledges and everything else that relies on their single-sign on accounts. This is meaningless to Joe home user or most small businesses, but vastly significant to enterprise level situations. With physical access to my work Windows desktop, you could gain access to some e-mail and word processing. With access to my system logged in as me on the Active Directory, you would have access to my AD OU, networked drives, SSO enabled applications, etc. See the difference?
2. A USB drive that automagically copies the last used files onto a flash drive. The ability to subtly plug a drive in and retrieve it later opens all kinds of espionage capabilities.
it is not really worse than just inserting a boot CD that copies the relevant data to a secure server or so.
Beyond the statements I made above, rebooting a system in a secured environment can easily trigger monitoring systems' alerting capability.
It can also of course easily be fixed by disallowing loading of USB drivers without confirmation from the user.
For anyone interested, here's instuctions on how to (theoretically) disable USB entirely under Windows. Note that I've not tried the above process described, so it may or may not work. And another one discussing how to disable USB storage devices, although that may not be enough to prevent the exploit in question from working.
Everyone seems to be forgetting the real big security issue with this.
Accessing physical data on the system's hdd (whether encrypted or not) is not the major issue - accessing currently running programs is.
Example - John Q Sysadmin has a few open ssh sessions to some of his favourite boxes - locks his workstation so he can wander off somewhere. Anyone exploiting this to unlock his workstation now has access to his logged-in ssh terminals.
Yes, there are other ways to achieve this, including keyloggers, trojans, etc, but this makes it stupidly easy to walk past a random workstation, and potentially 10 seconds later have root access on any number of other boxes the user happened to be logged in as.
Remember guys - better be shutting down your ssh terms before you go to lunch!
Attacks are not, but exploits can be, and this one is very creative.
I'm 41 and I've been in the software industry for 23 years, so I'm hardly a kid.