Slashdot Mirror
Aging Security Vulnerability Still Allows PC Takeover
Jackson writes "Adam Boileau, a security consultant based in New Zealand has released a tool that can unlock Windows computers in seconds without the need for a password. By connecting a Linux machine to a Firewire port on the target machine, the tool can then modify Windows' password protection code and render it ineffective. Boileau said he did not release the tool publicly in 2006 because 'Microsoft was a little cagey about exactly whether Firewire memory access was a real security issue or not and we didn't want to cause any real trouble'. But now that a couple of years have passed and the issue has not resolved, Boileau decided to release the tool on his website."
There is also another Security researcher who find an efficient way to gain privilege though the hibernation file. Slashdot news: http://slashdot.org/firehose.pl?op=view&id=551924
...finding a PC with a firewire port.
(The only ones at my workplace are the two I put firewire cards in. Don't ask, it's complicated.)
-Rob
Biblical fiscal responsibility
So why exactly is it a desirable feature for a firewire node to be able to access another node's memory unsolicited?
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
This does require physical access to a machine. If you want to access the machine, you can reboot using a USB stick and access the hard disk that way, or even just open the machine and take the drive, then modify the contents to your heart's content before putting it back
Not to say that Microsoft shouldn't have patched this, for it is certainly a design flaw to allow computers hooked up to a machine to access its memory, but if you're plugging something into the Firewire port of a computer, then you're sitting at that computer, aren't you? It's true of all hardware that if you have physical access, then you can do whatever you want with it anyway.
-Nick
Comment removed based on user account deletion
Maximillian Dornseif demonstrated this same Firewire vulnerability against Linux and OS X machines in 2005. Adam Boileau just gets more press because he performed the hack against Windows PCs.
____
~ |rip/\/\aster /\/\onkey
But this works with crypted drives.
This
That's not exactly the same.. Take my library for example all machines are set to boot correctly and the cases are physically locked to their location. Also looks a lot less suspicious when you're not ripping the guts out of a machine that it's obvious you don't own in public..
For Microsoft to have failed to patch an issue such as this must be indicative of either breathtaking arrogance or utter stupidity... or perhaps both
How about apathy? They'll wake up when and if they ever lose market share because of their shoddy product. I mean come on, if I can sell a Yugo at Escalade prices, why should I produce a quality product? That would be stupid. And if I could sell Yugos at Escalade prices I think my arrogance would be understandable and forgivable.
They've been selling an insecure OS for as long as PCs have been networked, why should they secure it now?
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
This though appears to have the advantage of not requiring a reboot, so rendering BIOS passwords ineffective.
It's all very well to say if someone has physical access all security is compromised. That doesn't mean you need to make it as easy and quick as possible. Now if you lock your computer and pop to the bathroom, a visitor could be in and out of your PC before you get back.
With this hack, you can spawn a command prompt with admin rights directly from the login screen. No reboot required.
____
~ |rip/\/\aster /\/\onkey
This same vulnerability also affects OS X as reported here: http://blog.juhonkoti.net/2008/02/29/automated-os-x-macintosh-password-retrieval-via-firewire
As well, as Linux, as reported in an earlier 2005 report about this firewire feature: http://www.matasano.com/log/695/windows-remote-memory-access-though-firewire/
A lot of workplaces will have physically secured machines but nonetheless with ports open. People might notice if you remove a server from a rack to access its insides, but just plugging in a cable?
Yes offcourse, not that many machines have firewire and servers are even rarer (although my pc has a port) but still, there is a major difference between the access needed to open a PC and gets its HD and just plugging in a cable.
See it as the difference between having to steal secret documents and being able to copy them at the spot.
If this tools indeed works in seconds then that is a lot faster then opening up a PC, taking out its HD, installing it in another machine, breaking its security, reading the contents you want (which at this point would give you only the contents on the HD, not the network), re-installing it and closing the cover and removing every trace of your access.
A lot of security is about inconvenience. Safes ain't rated for being unbreakable, but how long it takes to open them. ANY safe can be opened, the trick is making the process take so long that it can not be done without being found out. Thanks to MS, breaking its security has just become a lot more convenient.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Which is it?
This post expresses my opinion, not that of my employer. And yes, IAAL.
"You see, this serious security problem was designed in from the start, so therefore... it's not a problem! Ta-da!"
Here's the thing though: this requires physical access. That makes it a low-salience attack, because gaining that kind of access is only an iota easier than pointing a gun at someone's head and demanding their password.
Palm trees and 8
It's not Microsoft's fault, it's a hardware problem. FireWire is a peer-to-peer protocol with commands for using the DMA controller. Any device plugged in via a FireWire port can issue DMA requests. It can dump the entire contents of (physical) memory and write data at arbitrary locations. A FireWire controller ought to only permit DMA to and from regions the driver allowed it to, but most don't. The only work around for this is to either disable FireWire or use something like the Device Exclusion Vector on modern AMD chips to block the device's access to memory.
I am TheRaven on Soylent News
Comment removed based on user account deletion
Once your machine's physical security is compromised, just about anything can happen. If someone is in your data center or office unattended and hooking up equipment to your PC, you're sort of in a world of hurt anyway.
--I'm so big, my sig has its own sig.
-- See?
... it turns out, his site is vulnerable to the slashdot effect :)
Doesn't that also mean that Linux is also vulnerable to Apples firewire design faults?
Or perhaps slashdot on another uneducated baseless diatribe directed towards that little known company MS.
Did you read the article or did you just check the headline and decide to try get cheap mod points? Ill point out why you dont deserve them.
'Paul Ducklin, head of technology for security firm Sophos, said the security hole found by Boileau was not a vulnerability or bug in the traditional sense, because the ability to use the Firewire port to access a computer's memory was actually a feature of Firewire.'
Now maybe this was just excuses but the fact it came from a third party with no particular connection to MS should have made you pause for thought. Even if you dont know much about firewire it would take you moments to do a quick search and actually realise this is a 'feature' of the actual specification itself. As in _every_ O/S had the same problem. Linux, OSX even BSD were using this exploit even before MS were cracked. There are still reports of new OSX and Linux systems being hacked by firewire right in to 2008. (Though admitedly ive not heard much from BSD, probably because there admins tend to actually have a clue.)
This is a universal flaw in security stemming from naivety with regard to externally connected hardware. You want secure firewire, disable it when you are not using it yourself. That goes for any system, any O/S, any person. End of story.
One of the things I always hear in the USB vs Firewire debates is how much lower overhead Firewire is. In informal testing, this certainly seems to be the case. Well, one of the reasons it might be is if it has DMA. You'll find that's how a lot of PCI hardware works. It can read and write directly to memory, it doesn't have to do things through the processor. Keeps system load much lower, it'd quickly peg the CPU if it had to deal with shuffling around all data on the system. However, it also can lead to problems, of course.
Well, if Firewire has the same capability, it would explain why it is much lower overhead than USB, but it would also allow for things like this.
In general, DMA is probably something that needs to be looked at being cleaned up/reworked. It is a non-trivial cause of system instability: Hardware goes nuts (or maybe driver orders hardware to so something stupid), craps on memory it shouldn't system goes down. However anything like that is going to take a back seat to performance, at least in regular PCs. As nice as it would be to have the CPU fully in charge of everything, people aren't going to put up with it if it means a 10x drop in performance.
Because he linked to the main story. It's the same link in the summary. That's redundant.
maybe they aren't smart, maybe they are dumb, that means even a dumb ass can crack windows security.
What if Tetris was invented by Nazis?
Comment removed based on user account deletion
Some commenters note that this is a feature of Firewire. But would there be any problem with MS just disabling the port whenever the system is password locked, unless there is something already plugged into the port when the system was locked (after all, there might be a Firewire HD plugged in, and a process writing to it). Probably the best way to handle the latter case would be to watch for an unplug event when the system is locked, and then disable the port as soon as the device is unplugged. This is very simple, and I don't see any downside to it.
Or I could use a bootdisk with a password hash file modifier...
He didn't say it's not a problem, he said it's not a bug or vulnerability in the traditional sense.
It's also not a Windows issue, because it's the nature of Firewire itself. Which is why this hack can also be done on Linux and OSX, although TFA doesn't bother to mention this.
This is why my laptop has a big button on the side that enables/disables Firewire, and it's disabled by default on boot. I'd have to "opt in" to this vulnerability.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
You're wrong on two counts.
One, this is an outlet for "news for nerds". As unfathomable as it might seem to you, there are nerds who are into Windows. Some even by choice.
Two, this is not a Windows vulnerability. It is a FireWire vulnerability -- actually, a FireWire design flaw. It is possible that the OS could be careful enough to prevent this kind of thing, but none of the current OSes are:
I honestly can't say about Syllable or FreeBSD, but I know that neither Linux nor OSX have fixed this issue. There is an unstable fix for Linux, but it breaks some hardware.
The recommended fix, in all cases, is to disable your FireWire port when you're not using it.
So does complaining about a story merely because it discusses a Windows vulnerability. Maybe not everyone saw this as an excuse to point and laugh at Microsoft? Maybe only you did?
Don't thank God, thank a doctor!
You can't really blame Pongo. Cruella keeps trying to make beautiful coats from those cute puppies.
You can't talk about Wikipedia's flaws on Wikipedia
"So I tied an onion to my belt. Which was the style at the time. Now, to take the ferry cost a nickel, and in those days, nickels had pictures of bumblebees on 'em."
You can't talk about Wikipedia's flaws on Wikipedia
It is true that the DMA must write to RAM where the DRIVER tells it to. It is the responsibility of the Driver to not write data where the device tells it to, and do proper bounds checking.
hey now. Not all of us need this crack to bypass windows security.
Mind you I'm not a hardware guy, but I saw this very exploit used over Firewire on a pre-OSX Macintosh at MacHack years ago. The entire audience did the ew, ah, thing and withdrew in horror. Subsequently nothing was done to fix Firewire or the fact that remote devices could write whatever they wanted and exercise whatever privilege on the host device. I suspect that this is the same thing we see here and it is surprising that such a vulnerability exists. There's blame to go around, I'm sure but it seems unlikely if this is a hardware vulnerability that anything Microsoft could do would really fix the problem short of breaking Firewire support entirely.
Whose spec was this anyhow? While blame is shared according to Wikipedia, Firewire was Apple's interface design.
So what?
There's dozens of other ways to compromise a PC (Windows or not) if you can sit down in front of it. Even if you don't have to reboot with this, or can sniff enough stuff to log in remotely later across the internet...
This is why the server room and racks are locked, it's really really hard to combat against someone who as physical access and a bit of time/knowledge to use to evil ends.
Sure, it's creative but come on...
<technical bitching>
That's IEEE 1394 sir. IEEE is an institute.
</technical bitching>
Hey! That's my sig you're smoking there!
Sure, but if the system is live and has the EFS mounted, the key must be held in memory, otherwise the OS couldn't decrypt the EFS partition. With the key in memory, and Firewire having Direct Memory Access, the bad guy has the EFS (or PGP, or TrueCrypt, or whatever) key. That, plus passwords, web pages being viewed, engineering documents being edited, etc.
This is not a Microsoft vulnerability. FireWire devices can access RAM in the host machine, whether the host machine is running Windows, Linux, or MacOS. Any operating system running on a machine withe a FireWire port can be taken over in this manner.
Actually, ignore my comment about the Firewire button -- I've been up since 3:00 am. It just occurred to me that the button I'm thinking of actually enables/disables Bluetooth, not Firewire. My bad. I don't have the laptop in front of me right now, and of course I don't use either Firewire or Bluetooth, so I've never actually used the button in question. There's also a button to enable/disable wi-fi -- which I do use, and it seems to me that only works when the laptop is unlocked. Again, I don't have the laptop here to verify that.
So, going back to my original post, maybe there should be a button like the one I described, since this is the nature of Firewire and not a Windows problem as TFA suggests.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
Should be. It's a "feature" of Firewire.
Some Mac people figured it out early (at least by 2001)
http://rentzsch.com/macosx/securingFirewire
The FreeBSD people were already using it way back in 2002, quote:
"As you know, IEEE1394 is a bus and OHCI supports physical access to the host memory. This means that you can access the remote host over firewire without software support at the remote host. In other words, you can investigate remote host's physical memory whether its OS is alive or crashed or hangs up"
In other words it doesn't matter what OS it is or whether there is even an OS.
Oh yeah there's also "Linux Kernel debugging over Firewire" but that's recent - 2006.
Linux has this same bug. It's in "ohci1394.c". I reported this to the Linux kernel mailing list years ago, and the reaction of the kernel developers was to make it a "feature" for "remote debugging" that's enabled by default.
Technically, here's how it works. First, see the OHCI specification, section 5.15, "Physical Upper Bound register". This determines the highest memory address into which an external device can store directly by sending a packet. If set to zero, this feature is disabled. That feature is intended for slave devices, like peripherals. On computers with an operating system, it should be zero. It's not.
In the Linux kernel, that security hole was installed in "ohci1394.c" with the comment:
/* Turn on phys dma reception.
*
* TODO: Enable some sort of filtering management.
*/
In early kernels, it was unconditionally enabled. In 2.6, it's enabled by default, but can be turned off.
Also, This patch indicates that this security hole may have been designed into some FireWire controllers, so that the "upper bound register" didn't really do anything, but read back zero.
If you have an IOMMU (e.g. on a decent Sun workstation), you can set up page tables for each device so that they DMA into a virtual address space. Your driver can then define regions which the device can access transparently. On newer AMD chips, you have a Device Exclusion Vector (DEV). The DEV is a sort of IOMMU-lite. It performs access control, but not translation. This means that the host OS (or driver) can mark each page of physical memory as read / write accessible on a per-device basis. On these machines, a well-designed OS or driver could prevent these attacks.
On other systems, it is not possible to prevent this attack. It's also a known problem on FreeBSD and OS X. OpenBSD does not implement FireWire support for the explicit reason that it is impossible to do securely on most systems.
It is the responsibility of the Driver to not write data where the device tells it to, and do proper bounds checking. You are possibly confusing DMA with Programmed I/O (PIO). On a PIO device, the driver writes data to device-mapped memory or an I/O port, the driver then reads it from here and writes it to wherever it is meant to go. On a DMA device, the driver (or, in the case of FireWire, a remote peer) just tells the device where to write the data and it does so without CPU intervention.I am TheRaven on Soylent News
Sure, but if the system is live and has the EFS mounted
EFS isn't a partition encryption system, so there's no mounting involved. Each individual file has its own file encryption key.
What you said applies if the account whose data you want is already logged in and the machine merely locked, but not if the account isn't logged in, in which case the EFS key is not loaded yet and won't be decryptable without the real password.
(Bitlocker, on the other hand, is a volume-encryption system, like TrueCrypt.)
This "vulnerability" is basically irrelevant for notebooks. Most notebooks have hot-swappable CardBus or ExpressCard slots, both of which have DMA support and can be used to dump the system's memory. Or you could do the "memory freeze" trick.
The correct solution would be to map the FireWire address space into virtual memory, but this has to be done at the hardware level.
Ever since Macs have had Firewire ports, you can boot a Mac holding down the T key and its hard disk become accessible via Firewire cable on another Mac. Mac OS X setup even prompts you to do this if you're migrating settings & data from one Mac to another.
Up, Up, Down, Down, Left, Right, Left, Right, B, A, START
Yes, this Vulnerability affects every operating system supporting the FireWire specification equally, you can take over Macs and Linux computers as well as Windows computers.
In addition, the same problem exists with USB devices.
Here is a document describing the hack on Apple
Perhaps because this works even if the BIOS password is set? Even if the case is alarmed or otherwise secured?
If the attacking computer is small enough to be mistaken for a disk drive, you could even conduct this attack while being supervised.
There seems to be some debate over whether this can be fixed in software or not. If it can, Microsoft should do so. If it can't, the affected computers should be recalled. Bottom line: the situation is unacceptable.
Or more simply, bring an ipod with linux (or so one of the linked articles, or maybe something it links to, suggests), and plug it in. Presumably this is faster than booting a live CD. It also gets around any BIOS password.
Wait... Windows has security?
Actually, no.
Adding a firmware password to my PPC Macs puts them into a heightened security mode that turns off Firewire DMA (and was tested specifically with the hack you referenced). I would expect the Intel units to have this feature also. And the new Linux firewire driver tackles the DMA vulnerability issue too.
What I've read on the subject so far indicates that most or all Firewire chipsets allow operation without DMA, and that it is possible to secure the DMA modes by programming the memory controller to restrict access to specific buffers
FWIW, Apple was similarly "cagey" (actually silent) on the issue, but at least gave us the ability to secure the port through openfirmware.
What I would worry about more are the DMA interfaces that no one is discussing re: security... PCMCIA/PCCard and other hot-swappable ports (PCI-X? eSATA?) that support bus mastering. I'm pretty sure that non-USB-implemented CF slots are a risk.