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
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.