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."
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...
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?
Best of all, for attackers, the device drivers run with System-level privileges, giving an attacker full control of the host system once the exploit has been triggered. SPI tested attacks on Windows systems, but any operating system that is USB-compliant is probably vulnerable, he said.
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
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?
> 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.
If you're physically at the computer, you can reboot it and hit escape at the login prompt (or any number of other possibilities). Windows XP makes this rather harder than it was in Win9x, because it has filesystem permissions, so that if you don't log in you may not be able to access various files -- unless you boot from a Knoppix CD or the equivalent, of course, but that can be disabled at the BIOS level. This is why the USB exploit is significant -- there are many situations in which an attacker might have physical access but not totally *unobserved* physical access, and so taking the cover off the case is problematic, but inserting a USB keychain fob is possible. With Windows 95 that wouldn't have even been significant, because there were much easier ways to get at things.
Cut that out, or I will ship you to Norilsk in a box.
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
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
Well, if a current user is already logged in (But the workstation is locked), the filesystem is already mounted. You could then with this USB exploit access the whole filesystem easily.
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.
exactly how do you do this?
> easily be fixed by disallowing loading of USB drivers without confirmation from the user.
You can always encrypt the sensitive files on the encrypted hard drive. Use a very long passphrase and you got pretty good security, but with time it is crackable. I've seen it both ways, where the whole drive is decrypted with the key or where each application has to decrypt. Both have strong and weak points. It all depends on what you consider secure enough!
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.