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?

Previously: Did I Miss The Boat For Developer Keys?
Next Post: iPhone Developer Rejections Top 10,000

By: Jens Alfke
On: March 13, 2008
at: 6:56 pm
As: Computers
See: 8 comments;
Add: your comment

About

This is the blog of Jens Alfke.

Introverted, intuitive, thinking, perceiving. I live to make things: most often software, sometimes designs or mixes or stories or photos. (I wish I could make music.)

Father, husband. My home is a nest of family. Outside is overrun with flowers and vines and shade trees, inside with books and CDs and kids’ drawings and game pieces and game cartridges.

Worker, dreamer. I’m driven by visions of things that could be.

Contact

Send friendly correspondence to thought-palace at this domain.

On Thu, Mar 13 at 8pm,
Michael Brundage said —

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.

On Thu, Mar 13 at 9pm,
n[ate]vw said —

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.

I tried so hard, but left out a piece of Rentzsch’s last name, sorry. I even had the URL right there!!

On Thu, Mar 13 at 9pm,
Jens Alfke said —

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.

On Fri, Mar 14 at 2am,
Rosyna said —

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.

On Fri, Mar 14 at 8am,
Jens Alfke said —

OK, next step is to figure out how to enable the ~~OpenFirmware~~ EFI password. But I’m sure I can google for that…

To answer my own question: Here’s Apple’s support article.

On Fri, Mar 14 at 8am,
Chris Adams said —

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.

Physical Attacks via FireWire

8 Comments:

About

Contact

Recently

Unread Comments

Categories