Physical Attacks via FireWire
This is pretty scary — a proof-of-concept attack that disables authentication in Windows within seconds, just by plugging in a special FireWire peripheral. It’s well-known that with physical access to a computer you can compromise it; but generally that involves activities that are time-consuming or blatantly obvious, like rebooting from a CD or swapping out hard drives. This new attack, though, takes only a few seconds; and the peripheral might look as innocuous as an iPod.
Worse, what enables this is not a bug in a driver, but a feature of the FireWire interface; so (as I understand it) there’s no real way to disable it, short of disabling the FireWire port entirely. These slides by the author of the exploit describe it in more detail. It turns out that the FireWire protocol directly allows any device on the bus to read and write the physical RAM of any other device on the bus. (Any old-school BASIC programmers out there remember PEEK and POKE? Same idea.) That’s physical RAM, below the VM layer, so there are no access privileges; it’s all available. The drawback is that mapping from that to the virtual address space that the OS uses is pretty complicated, and then the attack has to locate the desired kernel data structures (in this case the ones that enable password authentication) … but it’s clearly do-able, and has been demonstrated on Windows XP.
Now I’m looking at that FireWire port on my MacBook Pro with some concern. It’s basically a hole into the innards of the kernel, bypassing any security mechanisms. I feel like my computer’s been trepanated.
(*Update:* The comments on Bruce Schneier’s blog post about this are interesting, particularly this one by Chris Adams:
I find it interesting to see the time delay between the Mac and Windows security worlds – the first Firewire DMA-based hack I remember was the 2002 FireStarter attack. Apple modified their drivers to disable device DMA by the time 10.3 came out.
This was very widely discussed in various Mac news forums, blogs, etc. and a few security conferences. At some point the Linux crowd started making the same fixes and yet, somehow, it took half a decade before this finally got the Windows security community?
March 13th, 2008 at 8:02 PM
Jens, hacking a Mac that you have physical access to is far easier.
First of all, the Mac OS defaults are no password locking on sleep or boot, so you probably already have full access to the user’s data.
Ignoring that, just reboot the machine and hold down cmd-S. You now have a root shell. It’s trivial from there to do anything you want, such as just deleting the tmp file that tells Mac OS X the machine has been configured and then rebooting, which will prompt you to create an admin (sudoers) account.
March 13th, 2008 at 9:29 PM
Rentzsh actually seems to have the definitive article on this (and it appears to have been up since November, 2004): http://rentzsch.com/macosx/securingFirewire
The way I understand it is that OS X will indeed disable Firewire DMA, all the way back to 10.2.2, but only if a firmware password is set.
March 13th, 2008 at 9:31 PM
I tried so hard, but left out a piece of Rentzsch’s last name, sorry. I even had the URL right there!!
March 13th, 2008 at 9:32 PM
Michael — First, I’ve turned on password locking. Second, rebooting and messing with single-user mode takes longer, and is more obvious during and afterwards.
March 14th, 2008 at 2:09 AM
Yeah, just enable the OpenFirmware password to disable FireWire DMA. It’s been like this for, like, forever. (Yes, I call it the Open Firmware password, even when you enable it on the ICBMs). But note, doing so may lead to a substantial speed decrease with high-bandwidth FireWire devices. IIRC, there was a bug in the very first releases of 10.4.4-10.4.something that made the password not disable DMA on the ICBMs. But this was fixed.
March 14th, 2008 at 8:20 AM
OK, next step is to figure out how to enable the
OpenFirmwareEFI password. But I’m sure I can google for that…March 14th, 2008 at 8:23 AM
To answer my own question: Here’s Apple’s support article.
March 14th, 2008 at 8:24 AM
nate - thanks for the link to Rentzsch’s article. I was looking for that yesterday.
Rosyna - has anyone looked into whether the current hardware offers support for restricted DMA? I last ran into this with cluster interconnects which were completely insecure at first but later acquired hardware support – probably motivated more by system stability than security.