USB Devices Can Crack Windows

USB Devices Can Crack Windows By Paul F. Roberts

Vulnerabilities in USB drivers for Windows could allow an attacker to take control of locked workstations using a specially programmed Universal Serial Bus device, according to an executive from SPI Dynamics, which discovered the security hole.

The buffer-overflow vulnerabilities could enable an attacker to circumvent Windows security and gain administrative access to a user's machine.

This is just the latest example of a growing danger posed by peripheral devices that use USB (Universal Serial Bus), FireWire and wireless networking connections, which are often overlooked in the search for remotely exploitable security holes, experts say.

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.

SPI is still testing the hole, and hasn't informed Microsoft Corp. about the problem. The company will be demonstrating the vulnerability at this week's Black Hat Briefings hacker conference in Las Vegas, but will not release details of the security hole, Sima said.

A spokesperson for Microsoft's Security Response Center confirmed that the company has not received a vulnerability report from SPI. The company strongly encouraged any researcher to contact the MSRC if they have a vulnerability to report.

Rest Of the Story is Here:

http://testing.onlytherightanswers.c...=article&sid=7

mmmm... thats interesting, USB (Universal Serial Bus) is obviously alot more universal than planned, I wonder if this exploit will work with LINUX if the following is true "Microsoft feels that this is a hardware issue and doesn't see it as a problem"

Quote:

---

Originally posted here by c0br4
mmmm... thats interesting, USB (Universal Serial Bus) is obviously alot more universal than planned, I wonder if this exploit will work with LINUX, probably not though.

---

Once a weakness like this is announced ("Without Giving anyone time to patch") it allows people to create proof-of-concepts and maybe even for Linux as well.





__________________
Where Black, Gray and White Hats Unite to help protect YOU from current and future Exploits http://testing.OnlyTheRightAnswers.com

There are a couple of points to consider.

In windows, when you insert a USB device, windows tries to load a device driver. So while Microsoft says it is a hardware problem, if it's a problem arising from how USB was designed, it is functioning normally and installing a driver. So we go back to Windows and security policy. If you have an account actively logged in (say, with a locked screen) and you install a USB device with an 'exploit' driver...


#1 where did the driver come from? Do these 'exploitable' drivers come standard with Windows installations?

#2 does the user have a priviledged account?

#3 why is Windows loading drivers without asking the users permission?


Now I know #3 is default behavior (I think...), but *WHY* is that? #2 is default behavior most places although it shouldn't be. And as for #1, if it's a default driver with Windows distros, then Microsoft DOES have a problem. If it does not, but it is installed after the fact (by disk, download, etc.) then you have a policy problem in your organization, allowing that driver.

P.S. I am pretty dissapointed in SPI Dynamics for getting themselves some PR attention via this supposed exploit without first having reported it to MS. That is not the best behavior, for a responsible company. I like those guys, they do good work and are decent folk (yes, I've met some of them), but that seems like pretty irresponsible behavior.

FYI, also saw a related thing with firewire...the drivers/implementations allowed direct memory access (in some cases write as well as read)...there were some rather amusing presentations at CanSecWest, one of which was 'Owned by an I-pod'). Not really an overflow, but rather taking advantage of the ability to directly read/write to memory, nonetheless, was interesting.

Quote:

---

Originally posted here by zencoder
[B]#1 where did the driver come from? Do these 'exploitable' drivers come standard with Windows installations?

---

As far as I have read the 'stock' drivers (Win2000 and up)..

Quote:

---

#2 does the user have a priviledged account?

---

Once the drivers are installed that doesn't seem to matter..

Quote:

---

#3 why is Windows loading drivers without asking the users permission?

---

Plug and Play baby :D


Btw, the link in first post of this thread seems to be a rip from http://www.eweek.com/article2/0,1895,1840131,00.asp
(they even copied the link texts, not the links)

Quote:

---

Originally posted here by the_JinX
As far as I have read the 'stock' drivers (Win2000 and up)..

Once the drivers are installed that doesn't seem to matter..

Plug and Play baby :D


Btw, the link in first post of this thread seems to be a rip from http://www.eweek.com/article2/0,1895,1840131,00.asp
(they even copied the link texts, not the links)

---

RE: Drivers loading and Plug and Play...

Yeah, I get all that...was posting in the form of rhetorical questions. Sorry, guess my 'tone' didn't come across too well. The point was, MS may claim it is not their problem, but if the defined behavior allows priviledged access, then it's poorly designed and/or implemented. I don't give a rat's ass if it's their code, an IEEE problem, or some dorkwad engineer who can't write a driver; it's an exploit, on their platform, and they need to address it.

</rant>

Quote:

---

Originally posted here by c0br4
mmmm... thats interesting, USB (Universal Serial Bus) is obviously alot more universal than planned, I wonder if this exploit will work with LINUX if the following is true "Microsoft feels that this is a hardware issue and doesn't see it as a problem"

---

Well, as I have implied above, it can only be a hardware issue in the sense that it's probably a lack of security in the specification of how/when a driver loads, when a USB swappable device is detected by system. If MS is following the standard provided (sidenote: is USB an IEEE standard? One would think so...) by the developers of USB, then any failures based on that standard can be said to be 'hardware problems'. I don't really think this is fair or accurate, but it could easily be their approach.

For this exploit to MAYBE work in Linux, you'd have to have a driver that could work with Linux memory functions and the kernel, and have a system that dynamically loads drivers when USB devices are added (i.e. hotplugging.) Hotplugging is standard in kernel 2.6, and has been available since at least 2.4 I believe (jinX, correct me if I'm mistaken.) So while the possibility is there, it will probably take longer...if at all, since any closed source solution will be poo-poo'ed upon by the community, and an alternative project will spring up at sourceforge within minutes. ;)

On linux the hotplug system is active in most modern distributions (both 2.4 and 2.6)..
The hotplug itself is a series of shell scripts mostly.

In linux the vulnerability would have to be in either the usb drivers (ohci, uhci or ehci) or some device driver like the usb-storage module, since theý'll all get loaded.

I don't know about any vulnerabilitys in either though..
And since they are all in the kernel itselve a fix will be readilly available for all distributions as soon as one is found..

I tend to think that this is exploit code, written into the Windows driver, that depends on the access available when the driver is loaded by Windows. So, while a malicious driver could open an exploit vector on the system, it is due to the handling of the driver by the insecure system itself. So in that sense, MS is correct.

Maybe I'm not explaining this clearly enough. It has to do with the design of open systems (versus closed systems... for the younguns amongst us, read that as 'open vs. proprietary'...that's close enough). So while it may not be an issue with the MS code itself, it needs to be acknowledged by someone. It's similar to a hardware keylogger; the PS2 ports and bus can't do much about that attack.