hack

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

Firewire cables

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:

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:

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.

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.

Creating 32768 bit RSA keys for fun and profit

Have you ever wondered how long it would take to create a 32768 bit RSA key with ssh-keygen? Well, I did.

   $ time ssh-keygen -t rsa -b 32768 -f ~/.ssh/tmp32768 -N foobar -q
   real    244m31.259s
   user    244m15.664s
   sys     0m4.736s

In other words, on my test system (AMD X2 CPU with 1.8 GHz per core) it took ca. 4 hours. This is likely very dependent on how much entropy you can get (and how fast), so take the numbers with a grain of salt. A second key with 32767 bits (one less) took 16 hours, for instance.

The resulting tmp32768 (private key) file is ca. 25 KB big, the tmp32768.pub (public key) file is 5 KB big.

There's likely no noticeable performance hit for ssh or scp AFAICS, as all data transfers are done with a symmetrical session key, not the RSA key itself. Only the initial connection "handshake" will take ca. 40 seconds longer...

And yes, 32768 is the maximum RSA key size you can currently create with OpenSSH, go file a bug report if that's not enough for you ;-) However, as I then noticed, this key will not actually work. When you put it in some authorized_keys file and try to login, the handshake will fail and the server-side will see the following error in /var/log/auth.log:

  sshd[xxxxxx]: error: RSA_public_decrypt failed: error:04067069:lib(4):func(103):reason(105)

I first thought I found an off-by-one error, but the 32767 bit key (one bit less) didn't work either. After looking through the OpenSSH and OpenSSL code as well as the RSA_private_decrypt(3SSL) manpage a bit, I saw that OpenSSH uses the RSA_PKCS1_PADDING parameter. My current theory is thus that some padding is making the key not work. I'm now creating a key with 11 bits less bits than 32768, let's see what happens. For the record, a key with 16384 bits does work just fine.

Anyway, I'll probably report this as "bug" (more a theoretical than a practical problem, though) as ssh-keygen let's you generate RSA keys which will never work in practice...

Flashing a BIOS the Linux Way (tm) using flashrom

There are a gazillion HOWTOs out there for flashing a BIOS image without having to resort to ugly "boot DOS from floppy" or "run Windows *.exe file from BIOS vendor" and other ugly stuff. Unfortunately, the proposed solutions are equally ugly (e.g. creating custom CD-ROMs which contain the "floppy" with DOS/Windows flash tools).

Folks, this is so much simpler than you think:

The flashrom tool (GPL'd, written for LinuxBIOS purposes, but works perfectly fine with proprietary BIOSes, too) will easily do what you want, on a running Linux system. No floppy crap, no CD-ROM crap, no DOS/Windows crap, no rebooting crap.

Install it:

  $ apt-get install flashrom

Detect whether flashrom knows about your chipset/mainboard/BIOS chip:

  $ flashrom

Read the BIOS image into a file:

  $ flashrom -r backup.bin

Write a BIOS image (proprietary or LinuxBIOS) on the ROM chip:

  $ flashrom -wv newbios.bin

WARNING: This will overwrite your current BIOS! Make sure you know what you're doing!

For the Debian-challenged, flashrom is available in source form too, of course:

  $ svn co svn://linuxbios.org/repos/trunk/util/flashrom
  $ cd flashrom
  $ make

The list of supported chipsets, mainboards, and ROM chips is limited of course, but it's constantly expanding. Contact us on the LinuxBIOS mailing list if you want other hardware supported (or even better: if you have patches!). In many cases adding support for new hardware is pretty easy...

Stuff IV

  • Finally. I finished the Battle for Wesnoth campagin Heir to the Throne. If you're interested you can download replays of my games (425 KB). Level 23 is missing, as I accidentally deleted the replay file :(
  • Some of you might already know this - SNES Mega Man X & X2 played simultaneously. "This movie is essentially constructed by taking one controller and wiring it into two SNES emulators at once. The same input is used to play both games to completion. In other words, the player plays two games simultaneously with one controller". This is a 48 minutes video. Absolutely insane!
  • Interesting concept - Multi-Cursor Window Manager, "allows multiple users to simultaneously interact with a Unix desktop environment".
  • Hm, invisibility...

Motorola A780 - My Shiny New Linux-Based Smartphone

Motorola A780
Motorola A780 Accessories

TuxMobil - Linux on Laptops, Notebooks, PDAs and Mobile Phones

It seems that I have become quite a gadget-whore lately. I'm spending all my money buying one gadget after the other, no end in sight...

Anyways, I finally got one of those fabulous Motorola A780, a Linux-based smartphone. Getting one turned out to be way more complicated (and expensive!) than what I thought it would be.

In the beginning, all sounded quite good: my cell phone contract with o2 is two years old soon, so I can get a new (cheap) cell phone. Stupidly enough, o2 doesn't offer the A780 in their shops and there seems to be no way to order one either (they do offer other Motorola phones, though). After asking the same questions in different o2 shops multiple times (and almost giving up), I accidentally saw the A780 in the local Saturn (a German electronics store).

And indeed, they sell the phone, and they can even prolong my contract with o2 (there's a dedicated o2 employee working in the Saturn store), so that I can profit in the form of a cheaper phone. Or at least that's the theory... In practive, however, I have a student-contract (saves me some bucks) which has the stupid "feature" that it can only be prolonged in o2 shops. Guess what, the Saturn guys cannot give me the A780 as they can't prolong my contract, and the o2 shop simply doesn't have the A780 at all. Argh!

After grumbling, asking around, googling, and even more grumbling, I finally decided to do the following: I got a new "dummy" o2 contract in the Saturn (yes, I'll have to pay that for 2 years) which enables me to get the A780 and to get it cheaper. I'll keep using my old contract and my old SIM card for simplicity and leave the new one untouched. If you take into account the money I'll spend on the new contract it doesn't save me too much money, but at least it's distributed across two years... I'll terminate my (new) o2 contract tomorrow, to make sure I don't forget about it (I don't want to have it any longer than the 2 years I'm forced to live with)... Stupid, stupid world we live in. Nobody should be required to perform such "hacks" in order to get the phone he/she wants...

Enough ranting now, here's some juicy details about the phone:

  • ARM CPU (at 400 MHz, I think)
  • 48 MB RAM, 48 MB on-chip flash memory, 256 MB Transflash card
  • 240x320 touchscreen
  • 1280x1024 built-in digital camera (can record videos, too!)
  • USB (device, host, OTG)
  • Bluetooth
  • GPS (+ it comes with CDs with maps of Europe)
  • Plays MP3s and videos
  • Can send SMS, MMS, emails, and has an IM client
  • and lots more great stuff...

For details on the hardware see this wiki page.

The only thing which I'm missing is WLAN, but once USB host support works (the hardware does support it), you can easily use a WLAN USB dongle...

I'm pretty sure I'll be having lots of fun with this thing, and I'll quite probably be contributing to the OpenEZX project, which was started by Harald Welte (of gpl-violations.org fame) and tries to create the first 100% Free Software GSM-phone using the Motorola A780 and similar phones. Judging from these blog posts by Harald, running your own 2.6 kernel on the phone is not too unrealistic anymore, and telnetting into the phone (via USBnet) seems to work fine already...

Expect more spammingblog posts about the A780 in future...

Syndicate content