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.
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/
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!"
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.
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.
"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
hey now. Not all of us need this crack to bypass windows security.
<technical bitching>
That's IEEE 1394 sir. IEEE is an institute.
</technical bitching>
Hey! That's my sig you're smoking there!
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.
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
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