Uwe Hermann - Physical memory attacks via Firewire/DMA - Part 1: Overview and Mitigation (Update)

This is part 1 of a series on articles about the Firewire security issues mentioned below.

For many years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. Basically, if you gain physical access to a PC or laptop which has Firewire ports (or PCMCIA/Cardbus/ExpressCard, more on that later) you can

read arbitrary RAM contents from the victim's system,
overwrite arbitrary RAM contents with whatever you want,
and perform many, many severe attacks based on the two issues above. Examples include grabbing a full RAM dump via Firewire (takes only a few minutes), grabbing ssh-agent keys, grabbing screen contents, modifying screen contents, bypassing login/password screens, and many, many more...

All of this is done by exploiting a "feature" of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what's going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you're vulnerable.

In this article, I intend to give a fairly complete overview of the available papers published on this issue, tools for testing the attacks, as well as mitigation techniques for various OSes. If I'm missing some important papers or tools, please post a comment!

Papers, Attacks, and Tools

Over the years a number of presentations and papers have been released with information about these Firewire issues.

Maximilian Dornseif et. al.

The first publication that I know of was done by Maximilian Dornseif, Michael Becher, and Christian Klein. They gave a number of talks on various security conferences on this topic:

Pacsec 2004: 0wned by an iPod (PDF)
21C3: Hacking with Fire / Feuriges Hacken - Spaß mit Firewire (PDF)
Cansecwest 2005: Firewire: all your memory are belong to us (PDF)
http://md.hudora.de/presentations/firewire/: further papers and demo videos

They also released a number of tools, Firewire libraries for Mac OS X and Linux, as well as small demo scripts which use those libs:

pyfw-20041111.tar.gz: Mac OS X Firewire bindings for Python, various demos
http://c0re.23.nu/c0de/pyfw/: Other versions of the above code
pyfw_linux.tar.gz: Linux Firewire bindings for Python (can be used with above demo code on Linux)
ipod-linux-pyfw.tar.bz2: Instructions (+ disk image) on how to turn your iPod into a Firewire attack tool

Adam Boileau

In 2006 Adam Boileau (a.k.a. Metlstorm) gave a talk called Hit by a Bus: Physical Access Attacks with Firewire (PDF) at Ruxcon 2006. In 2008 he then released a set of tools:

pythonraw1394-1.0.tar.gz: Python bindings for libraw1394 (Linux). Tools: businfo, romtool, 1394memimage
winlockpwn: Python script which can circumvent a locked Windows XP screen (an arbitrary password will log you in)
bioskbsnarf: Grabs/shows the BIOS keyboard buffer via Firewire (which often contains your BIOS password)

Peter Panholzer

As of early 2008 Peter Panholzer from sec-consult.com published a two-page whitepaper which says they were able to run a winlockpwn-like attack on Windows Vista via Firewire. There's not much information in the PDF unfortunately, and no tools were released, as far as I know.

David R. Piegdon

The most recent toolset and papers I know of are from David R. Piegdon (a.k.a. IosTrace), who gave a number of talks in 2007/2008 about the issue, and also released a toolset called SEAT1394.

2007: OpenChaos: hacking in physically addressable memory (no extra slides)
Easterhegg 2008: FireWire Hacking: paper (PDF), slides (PDF)
More papers here...
http://0null.net/software/SEAT1394/: tools and libraries for pyhsical memory access via Firewire/DMA: 1394csrtool, liblinear, libphysical, debug-sshkey, dump-memory, remote-ps, show-stack, snarf-sshkey, test-all-pagedirs, dmashell, ...

I'll go into much more detail on how the tools are used and what they can do in another follow-up article.

Mitigation

There are ways to eliminate or at least mitigate these attack vectors. The simplest and most secure way is to not have any Firewire ports installed (don't put Firewire PCI/PCIe cards in your PC, don't use Firewire PCMCIA/Cardbus/ExpressCard cards). Now, if you have a laptop with built-in Firewire ports, you have a problem, of course. In that case you could still physically destroy the port (by opening the laptop and cutting/desoldering stuff, or by putting glue/epoxy in the port in order to prevent any Firewire cables being attached). These are slightly drastic (but effective!) measures.

Note: Even if you don't have any Firewire ports, you're not automatically safe and secure. If your laptop has a PCMCIA/Cardbus/ExpressCard slot, an attacker can simply insert a PCMCIA Firewire card (for instance) in that slot. Chances are, that your OS will automatically load the driver for that card and also the Firewire drivers you'll need if you want to use the card for attaching Firewire devices. Game over. Your "secure" laptop is now vulnerable...

If you cannot (or don't want to) remove/destroy/disable your Firewire ports, the next best thing is to ensure that nobody except yourself ever gets physical access to your PC/laptop. This is hard to do for a PC, and almost impossible for a laptop, mind you.

Finally, there are some software measures you can use to prevent at least physical DMA access for Firewire devices:

Mitigation: Linux

Pretty much every Linux system with the "old" Firewire drivers loaded (kernel module ohci1394 et. al.) is vulnerable to these issues. Newer kernels now also ship with a new Firewire stack called "juju" (kernel module firewire_ohci et. al.) which may or may not have the same issues (not fully tested by me so far, will report back later).

Per default, all recent kernels, e.g. 2.6.26, are vulnerable, but see below.

Under Linux, simply using a kernel which doesn't have any Firewire support (neither built-in, nor as a module) is the most secure option. If you must have Firewire support you can load the ohci1394 module with the phys_dma=0 parameter to at least disable physical DMA support:

  $ rmmod ohci1394
  $ modprobe ohci1394 phys_dma=0

I have personally tested this on some boxes and I can confirm that it renders the currently published tools useless.

If you don't use Firewire at all, you can simply rmmod ohci1394, and (for a permanent fix) add the following lines in /etc/modprobe.d/blacklist and then (important!) run update-initramfs -u afterwards!

  # Prevent automatic loading of the ohci1394 module.
  blacklist ohci1394
  # Prevent manual loading of the ohci1394 module.
  install ohci1394 false
  # Iff we should ever load the ohci1394 module, force the use of the 'phys_dma=0' option.
  options ohci1394 phys_dma=0

As for the new "juju" Firewire stack, I'm not so sure. A few quick tests showed that the currently available tools don't work with the new stack, but you shouldn't feel too secure! AFAIK the new stack does support (or will support soon) physical DMA for Firewire, so it's probably just a matter of adapting the tools a bit (I'll do some testing/research on this later, as time permits).

Mitigation: Mac OS X

On Mac OS you might also be able to completely remove Firewire support from the kernel (but I don't know if/how that can be done, not sure if you can easily recompile Mac OS kernels, and/or if you even have buildable source code and toolchains for that). However, you can at least remove the Firewire support in the default Mac OS installation by unloading AppleFWOHCI.kext:

  $ sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext

Thanks to a Daniel Reutter for letting me abuse his MacBook via Firewire and for finding the above kextunload command line. We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore.

The tests were done on a Mac OS X 10.5 (Leopard) with all recent security updates applied. Please leave a comment if you can test other versions of Mac OS X...

Mitigation: Windows

As for Windows, well, I guess you're screwed. While Windows XP does implement sort of "protection" in that it only allows physical DMA access via Firewire to devices which "deserve it", e.g. iPods (or any other Firewire mass storage device, I guess) this can be easily defeated by having your attack PC/laptop pretend to be an iPod (see the romtool Python script by Adam Boileau).

The only remaining option I know of (short of removing/destroying Firewire ports or preventing physical access alltogether) is to disable the Firewire ports/drivers in the device manager (untested by me so far). If you do that, remember to also disable all PCMCIA/Cardbus/ExpressCard controllers, of course (see above).

So far I've tested Windows XP SP2 successfully with Adam Boileau's winlockpwn. Windows XP SP3 doesn't seem to work, though (winlockpwn likely needs tweaking). I haven't yet been able to test Windows 95/98/Vista, if you can verify one of them, please leave a comment.

Mitigation: OpenBSD/FreeBSD/NetBSD/OpenSolaris/...

On OpenBSD you're likely not vulnerable as OpenBSD doesn't have any Firewire drivers at all, as far as I know ;-)

As for FreeBSD, NetBSD, OpenSolaris, and other OSes I don't have any information. I might be able to test one or two of them in the nearer future, but please leave a comment if you have some information about whether they are vulnerable and/or how you can secure your system...

Further Resources

Conclusion

That's it for now. I hope you now have a good overview of these issues and how to protect. I can only urge you to take this problem seriously! Three or four minutes of leaving your laptop unattended are fully sufficient for an attacker to get a full forensic image of all your RAM contents for later analysis. This is at least as critical as the Cold Boot attacks, if not worse.

I will follow-up with more articles about some more interesting details on these Firewire issues, how to use the above tools, and I'll report on some of the stuff I was able to find in RAM dumps gathered via Firewire...

Update 2008-08-15: Added information on how to blacklist the Firewire modules on Linux (for permanent mitigation).
Update 2008-08-16: Added links to further articles. Windows XP SP3 doesn't seem to work with winlockpwn.

Is this, in a file in modprobe.d, enough to prevent this attack for Linux users who never want to use Firewire?

# prevent automatic loading
blacklist sbp2
blacklist ieee1394
blacklist ohci1394
blacklist raw1394
blacklist eth1394
blacklist dv1394
blacklist firewire-ohci
blacklist firewire-core
blacklist firewire-sbp2
# and just for paranoia, prevent manual loading
install sbp2 false
install ieee1394 false
install ohci1394 false
install raw1394 false
install eth1394 false
install dv1394 false
install firewire-ohci false
install firewire-core false
install firewire-sbp2 false

Yep, that (partially) works, thanks!

For the "old" Firewire stack it's sufficient to blacklist ohci1394 (and/or ieee1394, which ohci1394 depends on, if you want). However, you must also run update-initramfs -u after editing the blacklist file, otherwise the settings won't take effect on the next reboot (the modules will automatically be loaded while booting; manual loading after an rmmod will fail as expected, though).

Also, I recommend to also put options ohci1394 phys_dma=0 into the blacklist file in order to force that option to be used should the module ever get loaded (for whatever reason).

I've updated the article with some more info on blacklisting (for the old Firewire stack). No testing done on the new stack yet, so I've omitted that information for now until I have actually been able to test all of that...

Interesting, I'll try to validate/reproduce this. Note however, that newer Macs are partially EFI-based (AFAIK) so this may not apply there...

Update: Oh, and this will only work for Mac OS X of course (as it's a feature in the Mac OS X kernel). If you're running Linux on Apple hardware for example (macbook, macmini, etc) then setting an OpenFirmware password will definately not help! So be careful and always test if you're affected.

Since disabling physical DMA on Linux is trivial and effective, should the various Linux distributions ship with "options ohci1394 phys_dma=0" somewhere in modprobe config by default? What would that break in userland? Would the breakage be worth the added security?

I can set phys_dma=0 myself, but I would rather have distro have it by default so that I do not have to think about it each time I set up a new machine...

I have an iBook G4 running Leopard, and I toasted my FireWire controller. This caused all sorts of problems, until it occurred to me to disable the FireWire drivers. You don't need to recompile the kernel: just remove all of the kexts in /System/Library/Extensions that contain the text "FireWire" in their name. Then, remove /System/Library/Extensions.mkext (or, in Leopard, this file will be automatically rebuilt when you remove the extensions).

Reboot, and your FireWire port is no more. Thus, if you are worried about security, and don't use FireWire, you can rest assured that it won't be a vector of attack.

Of course, expecting real security on any machine to which attackers have physical access is a bit foolish.

That's a good question. I don't know if there would be any breakage, but I expect slowdowns for devices which make heavy use of DMA (disks, video cameras, for instance). But I haven't tested any of this, I'm just guessing here...

Yes, completely disabling Firewire via removal/destruction, in the BIOS/Firmware, or in the kernel/drivers is the best thing you can do if you don't ever use Firewire.

My Mac will be at your mercy once again, I suppose.
So be it, next time we meet.

There's another option that seems to have been overlooked. Many (if not all) motherboard BIOSes have the option of disabling the firewire ports and likely PCMCIA ports as well.

Maybe, but it depends how the "disable" is done (which might be BIOS and hardware-specific). I wouldn't trust that unless you actually tested that disabling those options really spoils this specific attack.

Uwe.

Did you determine if disabling ohci 1394 in device manager prevents the attack in xp sp2?

I was wondering if you knew what the advantages to implementing DMA in the hardware, without the intervention of the OS is?

Just to be clear, this attack is valid if your computer is asleep or powered up with the key in memory, correct? Shutting down a computer that doesn't unlock the drive without manual authentication should ensure that nothing in memory is of any use to an attacker.

So, for example, when traveling across borders it's a good idea to power down your computer rather than just sleep it.

On OS X as noted here:
http://matt.ucc.asn.au/apple/

Setting security-mode to anything other than 'none' puts the firewire controller into secure mode, disabling Firewire DMA. This is effective even without setting a firmware password:
nvram security-mode=NONE

???
What a question ! See on Google "Direct Memory Access" and you'll have a lot of articles about it...
Else this link too :
http://www.omninerd.com/articles/Firewire_Interface_Hack

Papers, Attacks, and Tools

Mitigation

Further Resources

Conclusion

Latest Images