| Date: | November 29, 2006 / year-entry #397 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20061129-48/?p=28883 |
| Comments: | 43 |
| Summary: | Remember the Ten Immutable Laws of Security. Today, we're going to talk about number three: If a bad guy has unrestricted physical access to your computer, it's not your computer any more. There was a bug which floated past my field of vision many months ago that went something like this: "I found a critical... |
Remember the Ten Immutable Laws of Security. Today, we're going to talk about number three: If a bad guy has unrestricted physical access to your computer, it's not your computer any more. There was a bug which floated past my field of vision many months ago that went something like this: "I found a critical security bug in the USB stack. If somebody plugs in a USB device which emits a specific type of malformed packet during a specific step in the protocol, then the USB driver crashes. This is a denial of service that should be accorded critical security status." Now, it's indeed the case that the driver should not crash when handed a malformed USB packet, and the bug should certainly be fixed. (That said, I'm sure some people will manage to interpret this article as advocating not fixing the bug.) But let's look at the prerequisites for this bug to manifest itself: The attacker needs to build a USB device that is intentionally out of specification in one particular way and plug that device into a vulnerable machine. While that's certainly possible, it's a lot of work for your typical hacker to burn a custom EEPROM with USB firmware that manages to hit the precise conditions necessary to trigger the driver bug. It's much easier just to grab a fork. You see, since this attack requires physical access to a USB port, you may as well attack the machine in a much more direct manner that doesn't require you to spend hours with a soldering gun and a circuit board: Just grab a fork and jam it into the USB port. I haven't tried it, but I suspect that will crash the machine pretty effectively, too. If you can't get the fork to work, pouring a glass of water into the USB port will probably seal the deal. Doron tells me that some companies address this problem by removing physical access: They fill the USB ports on all their machines with epoxy. Update: Randy Aull tells me that the USB 2.0 specification anticipated the fork attack and requires that all transceivers be able to withstand short circuits "of D+ and/or D- to VBUS, GND, other data lines, or the cable shield at the connector, for a minimum of 24 hours." (Though I'm not sure if that also covers shorting VBUS to GND.) I wonder if they also have a paragraph specifying that USB devices must also withstand water immersion... Of course, you could still use that fork to push the power button or jam it into an outlet on the same circuit as the computer you want to take down in order to blow a fuse. |
Comments (43)
Comments are closed. |
Your analogy ignores the trend now towards wireless USB. This allows an attacker to be at distance from the machine. While such an attack would be unlikely and preventable, it is still possible.
The reason why it was considered more dangerous than "the fork attack" is that most of the crashes don’t end as denials of service — that is, there is a (somebody guessed significant) chance that the person who manages to craft the packet can craft it in such way to be able to 0wn the machine (that is, not stopping it, just getting access perimissions).
Imagine that you can carry in your pocket the device which adds your username and password to any Windows machine.
Having access to a USB port does not imply unrestricted physical access to the rest of the computer. It may be the case that the main box is sealed away somewhere but a USB hub is provided on the desktop (e.g. at internet cafe) for users to plug devices into.
So, if the fork attack is prevented, and pouring water over the hub just renders the hub unusable, fixing this would be a nice way to give the user one less way to break stuff.
(Not sure if the USB DMA attacks[0] have been fixed yet, which probably are critical in such a situation, but that’s another matter entirely.)
[0] http://www.schneier.com/blog/archives/2006/06/hacking_compute.html
Forks, water… kids nowadays have it too easy. I remember that we had to use chainsaws and dynamite in order to bring down the mainframes.
Kind of gives a whole new meaning to the whole "forking the source" expression. :-)
If the crash cannot be used to run code of the attacker’s choice, this security breach is unimportant. But if the attacker can influence what happens during the crash, consider the following scenario:
I wish to 0wn your computer.
1. I know which make of USB stick you use to make your backups.
2. I make a bogus USB stick that causes the USB stack to crash in a way that causes some code of my own to run.
3. I swap it for your real USB stick.
4. The rest is left as an exercise for the reader…
Note that the bad guy doesn’t have to go within a mile of the computer that is being attacked.
Fork is not equivalent because the vast majority of computer owner over the age of 4yrs would not put the fork in the USB drive. The ‘Hacker’ simply needs to ensure that the computer owner is given/purchases the USB, then the owner plugs it into the computer themselves while the hacker is enjoying a nice cup of Tea somewhere else.
I’m still a bit confused because I read that only the USB device (driver?) crashes, not the whole machine. That’s hardly a hack, that’s more like making a device that doesn’t work. A fork without prongs?
Somehow the statement about bad guys (AKA hackers) "p0wning" your computer doesn’t seem to fit in the same category as someone sticking a fork in your USB port or pouring water on it. That’s like spending months planning a break-in to the Louvre so when you finally succeed in bypassing security you can pee on the Mona Lisa. (?!)
There’s a big difference in my mind between crashing a driver with a malformed USB packet (with the intent of a code injection attach), and shorting out the circuit the PC is plugged into by sticking a fork in the wall outlet!
ObOnTopic1: I’m not very good electrically. So would sticking fork tines on pins 2 and 3 of a USB port pull D- or D+ to 3.3V? If so, how far would the USB HC driver get before the signalling bombed out?
ObOnTopic2: BTW, Raymond, which USB driver are you talking about? The HC driver? USBD? A USB client driver?
I can tell you from personal experience that at least one implementation of USB 1 didn’t follow rules like this, as I have in the past fried a motherboard by plugging a scanner into a front-panel USB port that had been plugged into the motherboard the wrong way round.
The fault was entirely mine (well mine and the dodgy english translation on the piece of paper that came with the usb headers), and I realised my mistake when the PC made that ‘winding down’ noise the moment I plugged the scanner in.
Needless to say that when I plugged the front panel usb socket’s cable in on the replacement board I ignored the instructions and traced the wires from end to end before plugging in.
So this sort of situation is probably why the USB 2 spec required it withstand short circuits.
Unfortunately I can also tell you from personal experience that jamming a fork into a power socket for any reason (including attempting a DoS on a neighbouring PC) is not an entirely good idea. In mitigation I’d like to say that I was only four years old at the time, and I wasn’t actually trying to create a DoS, I was just an over curious child.
When I worked at a PC OEM, we had a modified mouse whose right button triggered a short. It had some red tape around it, and was known as "the mouse of death".
It was brought out whenever a mainboard vendor came to sell us a new motherboard. At the time, win95 OSR 2 was just coming out with USB support, and short protection wasn’t up to spec on all mainboards.
There’s nothing quite like a prototype PC giving up the magical blue smoke and refusing to work to put a salesman out of step.
By now all PCs should be tested with short protection on the USB and (firewire) sockets. If you are not convinced, go make your own mouse of death and take it to your nearest PC or apple showroom,
I’ve always wanted to follow this up with the Cat-5-cable-of-doom, which would have an AC plug on one end, and Cat-5 on the other. Go deal with that, my little networking stack…
But if the crash is symptomatic of some sort of buffer overflow where code execution could take place then, it is a big issue. You walk away from your computer, you lock the screen, I come by and plug in the USB stick and now unauthorized code is running.
In other words, "fixing" the bug doesn’t eliminate the denial of service attack…
Technically, slamming a hammer into a hard-drive while Windows is running will cause it to "crash"; what "bug" do you fix to avoid that denial of service attack?
Shortly after I bought my laptop, I lifted the base up at the front (probably to release the battery catches) without unplugging one of the cables in the rear-mounted USB 1.1 sockets. And it snapped off the piece of phenolic board that protects the four pins.
Now, about every one time in 20 that I plug something in to that socket, I do indeed get a short and the whole pc instantly turns off off protectively. I have to remove the battery and power cable to get it to boot again :)
Uh, that’s Raymond’s point. If you follow and read the "Ten Immutable Laws…" link you’ll understand that the fix to the ‘hammer’ bug is to remove physical access to the machine.
Not all computer-related bugs are software bugs. Some are hardware bugs and some are policy bugs.
The "Ten Immutable Laws of Security" are nice, but (like all simplifications) are a bit off for unusual situations.
Examples: kiosk type of machines, with partial physical access (Diebold?)
In fact, the rule is clear: "If a bad guy has UNRESTRICTED physical access"
But, anyway, a DoS attack might not be a really bad for a Diebold machine, but a buffer overflow would be a disaster (or it might be good, depending who uses the exploit ;-)
Aha, I see two brilliant use(s) of this attack vector now.
1) Create said USB device, label with ficticious company name and your number. Hand out free at security trade show. Users plug in usb device, ports freeze, irate users call you. You offer/ask to visit and resolve their issue. While there you investigate, thereby gaining physical access to their machine. You leave them satisfied but owned.
2) Create said USB device, counterfeit label like competitor’s device, distribute at trade shows. Additionally, share design with Chinese counterfeiting operation, encouraging huge production run. Bye-bye competitor as bad products mar reputation.
It is Microsoft’s duty to protect us from such things, you dropped the ball.
Steve: Ever read the old BOFHs? One of the earliest ones had him using an "etherkiller"; basically it was exactly what you’re talking about. It had an AC plug on one end, and an Ethernet plug on the other. (Of course, it’s fiction, but still.)
Yes, I remember that. Though I bet that story dated from the days of shared ethernet where you could fry the entire floor off a single shared ether. Now with switched networks you’d just take down a single hub.
On the topic of legacy-shared-ethernets, we used to have some prototype network management hardware called a packet-stomper. Its aim in life was to find whoever had a pc with a particular mac address, usually because (in pre DHCP days) the device had a bad IP address. The packet stomper would be given the target mac address and whenever the target device sent a packet, the stomper would transmit at the same time to create a collision. The effect would be to take the machine off the network. The owner of the said machine would invariably call up IT and complain their machine wasnt working.
Effectivley we were using packet collisions to identify errant devices, forcing their owners to confess.
I think with WLANs we could bring this idea back into being, though dont fancy writing the driver-level code it probably requires.
BryanK and Steve:
There’s actually a Japanese (IIRC) spec that requires Ethernet devices to be able to handle mains voltage on the network cable for a short time. Since most network vendors sell in Japan, most Ethernet devices comply to this spec and will not smoke – at least not right away.
Obviously, your network connectivity may be somewhat impaired during this event.
Or, you get a standard, functioning USB disk, put a hidden autorun.inf on it and run whatever you want with the user’s credentials. I saw a virus spreading like that. I know that security requires turning off autorun, but how many people do that?
A few years back I spent some time playing around with USB circuits, and got quite familiar with the Windows’ "Current limit exceeded" balloon. Controller simply disables the
offendingport and keeps on truckin’.(No reason—this post just brought back some memories ;)).
Jonathan, interestingly enough, that attack vector is exactly the reason that Vista prompts the user on autorun.
Note that since NT4 at least, the OS does not autorun a CD until the user is logged in/active. If you stick it in a machine while the user is logged off, or while the screen saver is live, it waits.
That’s to stop you autorunning a file on a locked system. Of course, once they log in, the box is 0wned. The whole autorun design predates ubiquitous CD-RW drives, and assumed that autorun CDs would only come from well-meaning software vendors. As such, its the physical equivalent of ActiveX.
Years ago, Windows 9x would crash if two USB hard disks with the same serial number were plugged in at the same time. Common sense would dictate that serial numbers are unique but that apparently escaped the attention of some el-cheapo USB disk manufacturers.
This is a software problem because some piece of "software" assigned the same serial number to two different devices. :=)
Point is, it isn’t as hard to find "malicious" hardware as you might think. There’s lots of incompentent programmers making products that can crash Windows – for that matter, anything else that isn’t paranoid.
Microsoft has since fixed their end … and in fact actually tests serial # uniqueness in their HW Compatibility Test.
—
It is actually very easy to construct USB device. Use PIC USB series of microcontrollers, you just need to build a cable which goes to serial port for programming and you get a lot of example code with it so you can craft whatever you want, and I presume even buffer overflows.
When we are at it, has the Firewire DMA exploit been fixed?
Steve,
The autorun-on-logon vector doesn’t work on XP (and I believe not 2k…but I might be wrong). You have to actually open explorer and double click on the cd, or eject and reinstert it, to trigger autorun. Doesn’t happen on logon or unlock at all now.
Its great to see that 99% of this blog’s readers can’t tell the difference between a ‘denial of service’ attack and ‘buffer overflow’.
Well I think the legal owner of a machine knows if they’ve been subjected to a denial of service attack but doesn’t necessarily know if they’ve been pwned by an exploiter of a buffer overflow.
My previous comment got something exactly backwards though. "The real owner" should have been "the legal owner". The real owner kn000ws what they pwn.
By the way a few days ago I saw an anti-spyware process occupy 98% of the CPU. The former owner had previously downloaded some spyware, I had reinstalled Windows and explained spyware to him, but he downloaded it AGAIN. So sometimes the legal owner even knows that they’re not the real owner any more and they DON’T CARE. My guess is that the spyware and anti-spyware are still fighting it out.
I think it’s a bit odd to bring up a hardware problem as an excuse to not fix a software development problem. Bad drivers don’t deserve that, especially when your OS runs them in kernel mode and gets the blame when it goes down.
We’ve actually done that in "secure labs" at Microsoft, too.
It used to be said that the only way to make a computer truly secure is to pull out all of its cables and put it in a locked room. Unfortunately, that’s not necessarily true anymore.
You could theoretically lock a laptop up in a room with nothing plugged into it, yet still manage to send it a packet (from outside the locked room, of course) that causes a buffer overflow in a wireless device driver and lets you 0wn the machine!
Naturally the implication is that if the computer is not plugged in, it must be turned off, which must be explicitly spelled out in the case of a laptop. Fortunately for an attacker, it is probably possible to simulate a wireless keyboard with a power-on key to turn on the laptop before sending it the fatal packet.
"pouring a glass of water into the USB port will probably seal the deal."
I did a similar attack on my PC’s power supply a couple of days ago and I can tell you it was very effective! DOS, you bet!
> (That said, I’m sure some people will manage to interpret this article as advocating not fixing the bug.)
Because you are. You are arguing (making claims) against the seriousness of this flaw.
Why isn’t it surprising a ms employee is doing this.
“Don’t try to fix the bug, for that is impossible. You must realize the truth: there is no bug.”
implies “bug doesn’t need to be fixed”. Are you saying that only
critically serious bugs need to be fixed? -Raymond]
"Because you are. You are arguing (making claims) against the seriousness of this flaw."
I disagree – this is a DOS attack against a machine to which the attacker has physical access. The risk of this happening is very small – it is maybe even just theoretical.
If there were infinite resources available, then "all bugs" could get fixed, but since that is not the case, Microsoft should focus on the bugs that matter.
After a fork attack I think the real owner knows about the fork attack.
After becoming pwned the real owner might not know. In cases of unrestricted access the USB route doesn’t add to this danger, but in cases of restricted access ("please attach this Zune for a moment") it does.
Speaking of other routes, I used to have a CD which would make some NT4 service pack (probably SP4) BSOD just by inserting the CD. This was one of the things that prompted me to reinstall NT4 and stick with SP3.
Wednesday, November 29, 2006 12:32 PM by Steve Loughran
> At the time, win95 OSR 2 was just coming out
> with USB support, and short protection wasn’t
> up to spec on all mainboards.
2.1. 2.0 didn’t have it.
Wednesday, November 29, 2006 1:58 PM by Mitch
> There’s actually a Japanese (IIRC) spec that
> requires Ethernet devices to be able to handle
> mains voltage on the network cable
Maybe because it’s soooooooo easy to mistake the port and plug a phone cable into the LAN port instead of the modem port. Yes I know how to count (the connector with 4 prongs means it has 2 conductors, etc.) but it is still soooooooo easy to make that mistake.
> for a short time.
Thank you. For some reason I’ve often worried about whether my puns were bad, but at least they’re not *that* bad.
I didn’t understand some aspects of the article. Should a "New device detected: Fork" Plug-and-Play pop-up appear, like the "New device detected: Boeing 747" one? <http://blogs.msdn.com/oldnewthing/archive/2005/10/24/484129.aspx>
[I should become a professional psychic. I wrote in the article, "(That said, I’m sure some people will manage to interpret this article as advocating not fixing the bug.)" And it came to pass. -Raymond]
You’re very intuitive. You’d probably make quite a good psychic if you could manage to act well. The withered hand may help the whole mysterious voodoo look, too.
2006 is nearing to an end. Any word on your prediction?
http://blogs.msdn.com/oldnewthing/archive/2006/05/23/604743.aspx
Yes but can the motherboard survive a sandwich?
Here’s the story: my roommate set up a new computer for his friend who lived 300 miles away. This was maybe 2 years ago. He was driving back over there to visit family anyway so he just brought the computer along and dropped it off. Everything was great until a few months later when the computer mysteriously stopped working. None of the usual troubleshooting steps worked ("unplug it … hit the reset …"). My roommate gets the computer shipped back over here and neither of us can figure out what’s going on.
Eventually after trying all the standard diagnostic steps, I started unplugged everything from the motherboard, after which it worked. Through process of elimination we come to find it’s the USB header, which goes from the front of the case to a row of pins on the motherboard, which is preventing the system from booting up and even getting to the BIOS screen. If it’s plugged in, nothing. If it’s not plugged in, the system works just fine.
We were content to just leave the front USB ports unplugged, but then I looked at it and noticed something weird. You see, the USB port is a rectangular metal shield which houses the four USB wires (data, ground, power, ground … afaik) which are stuck on to a piece of plastic. The piece of plastic was gone and the four wires were loose — and one of them was pushed straight down on to the enclosing metal shield. This caused a short and the motherboard could not boot up.
To fix it we just yanked out the entire casing for that 1 front USB plug. My roommate concluded that his friend (we’ll call him "D") had tried to do something less than agile, "Knowing D he probably tried to plug a sandwich into it." Well, whatever he plugged in was then subsequently yanked with enough force and in the wrong direction so that the plug was eviscerated.
So don’t plug sandwiches into your USB ports.
[i]There’s actually a Japanese (IIRC) spec that requires Ethernet devices to be able to handle mains voltage on the network cable for a short time. Since most network vendors sell in Japan, most Ethernet devices comply to this spec and will not smoke.[/i] — not until someone touches the casing, that is.
This is such an excellent post. It appears that people not only missed Raymond’s comment about "people will manage to interpret this article as advocating not fixing the bug", but Raymond should have also written: "People will assume that this security flaw is exploitable".
I think it’s a flaw in the USB driver, and certainly should be fixed, because nobody wants their computer to crash because of a bad USB device. However, I would also say that it’s much less serious than a buffer overflow. It only happens with a specific kind of BAD USB device. People who make such USB devices should be testing their devices, and none of them should crash the computer with their normal operation.
Yes it’s a bug. I bet someone fixed it. Raymond’s analysis is right, but people are known to overanalyze. Rick Brewster’s story above is funny. Apparently if you munge your USB port, you might find that you can’t boot the computer.
There’s a class of people who seem to believe that any bug is a critical security flaw. Point to consider:
Many years ago, I worked on an open-source assembler project which you may have heard of. Towards the end of the time I was working on it, we were contacted by some guy who reckoned he’d discovered a critical security vulnerability. There was a buffer overflow in the preprocessor, exploitable to run arbitrary code. Just dump it into the input file, assemble it, and it runs.
Just what you’d be doing assembling code you never intended to run anyway I never did figure out. Still, it earned the guy credit on his vulnerability-development course.
I find an axe a far more useful tool to screw up my colleagues computer! (or mine when Windows crashes for the tenth time today!!)