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."
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.
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.
Security is all about deterrent.
/dev/random > /dev/hda & well then a locked box is probably all you need.
Actually, security in this case is about doing a calculation of the worth of what it is you're protecting against the cost (be it a cost in terms of cash for access controls, or a cost in terms of user convience and system functionality) of the security. I've seen financial instituations who had all their workstations in a central computer room and just ran KVM terminals to each desk. The server room looked more like a vault. It was important to them to keep the workstations secure. On the other hand if you're a library and your only trying to keep them secure so that you don't have to reinstalls every week because some 12 yr old types cat
It's just like insurence really, you sit down and calculate how much your information is worth. After you do that, you put into place access controls equal or greater then the value.
Min
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
Never forget the manual option. It's easy to disable a USB port by epoxy ;)
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.
There are also PC's around (eg, some IBM/Lenovo ThinkCentre desktops, Thinkpad Laptops and also some HPaq Notebooks) where this will do no good. Where de-soldering the security chip is about all you can do.
Not impossible, but it'd be easier to take the HDD out (unless of course it is also encrypted with the TCPA chip)
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 concept of physical access required is insane at best. Done right, almost any device can be re-flashed, if a buffer-overflow is created by a payload, not only can the drivers be infected but the flash-memory itself can be infected. A good example is this: http://www.geocities.com/mamanzip/Articles/Low_Cos t_Embedded_x86_Teaching_Tool.html
Note: this was done using the boot-from-lan option for testing, most devices can execute code at boot, no mater what the boot-from option is.
As software becomes more patched, I would worry about legacy harware in the future. This is one of many exploits heading in that direction.
Black Gray White Hats Unite to protect http://testing.OnlyTheRightAnswers.com
I could also break into the system by using a boot floppy or CD.
I could then reset the domain servers's root password.
Or I could simply pull out the hard drive and take it home.
Controlling physical access is an important and often neglected part of computer security.
In a world that is Free and Open, who needs Windows and Gates?
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.