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."
...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
This isn't the first guy to get frustrated with Microsoft's lack of commitment in the security vulnerability area and just release his nasty onto the world.. It probably won't be the last either.
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
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.
"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
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?
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.
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...
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!
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.
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...
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.
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
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.