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
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
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/
<technical bitching>
That's IEEE 1394 sir. IEEE is an institute.
</technical bitching>
Hey! That's my sig you're smoking there!
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.
No - DMA may help in some cases, as you describe, but you can tell a Firewire drive to copy to another Firewire drive when neither has any physical memory and it will still copy much faster than USB. The lack of a centralized controller (and device registration, scheduling, etc) actually helps keep overhead down. Note that USB can't do that - Firewire is peer-to-peer, meaning each device is aware of other devices in the chain. USB is a master-slave star network and needs a host controller (e.g. a PC).
Firewire was built a hot swappable, high speed replacement for SCSI, and is really more analogous to SATA than USB, but people compare them because they're both used as external buses for peripherals. USB was designed explicitly as a low speed, low power, low cost small peripheral handler (e.g. mice and keyboards) to replace a variety of miscellaneous specialized plugs such as game ports, parallel port, serial port, etc, and thus cost was most important and speed least. Firewire put speed first and cost last. As far as Firewire goes, I think a battle may be coming, with SATA's external plug eSATA, as I expect it to make some gains in the peripheral market, especially in storage. eSATA actually has an advantage over Firewire, because the actual device used for storage is often IDE and therefore Firewire has some conversion to do (ATA is the protocol, IDE the device - often they're used interchangeably).
The problem here is gullibility. Think of it like social engineering - someone calls and asks "We are verifying your bank account pin, can you give it to us?" and you saying sure - it's 1234! That's a lot like what this program is doing. In this case, the device at one end is saying can I have access to your memory? And the device on the other end is saying sure, despite the fact that that giving write access to memory is a lot like giving away your bank account pin (which is why it's really an OS issue, not a firewire issue). Some OS's like Linux only give read access, which means you can see what is in the account, but not take anything out, but Linux (and Windows) allow this to be set by the foreign controller, which is a bug.
DMA access should be limited to non-system memory, if allowed. Unfortunately, that isn't very controllable by current computer designs. I believe the solution proposed and implemented (I've heard about this for Windows 8, I believe) is encrypted floating addresses, so even if you have direct access to memory you don't know where to write it.