Simon Says – Musings of a Technology CTO

For those who follow these kinds of things, you’ll remember that back in 2004 an enterprising group of people (Maximilian Dornseif, Michael Becher, and Christian Klein) gave a series of talks on how to bypass many kinds of computer security using the FireWire ports. This attack, though obvious from reading the specification of the Firewire / i.LINK / IEEE 1394 bus, simply used a computer acting as a “rogue” device to read and modify any memory location on a target PC.

Yes, ANY memory location, and that’s quite supported, even required by the FireWire/iLink specification, which needs direct-memory-access for some devices (like iPODs) to function.

Enterprising people have written attacks that use this “exploit” to get around encryption products, and locked workstations on Mac, Linux and PC.

The original presentation on this attack has been followed up by many more, (CanSec West for example, and others such as Adam Boileau (Hit by a Bus: Physical Access Attacks with FireWire), Peter Panholzer (Whitepaper: Physical Security Attacks on Windows Vista (PDF), and David R. Piegdon (2007: OpenChaos: hacking in physically addressable memory) have entered the fray. A comprehensive list of papers is maintained somewhat by Uwe Hermann.

Why does this attack exist?

Why this attack works is a little illogical, it hinges on the fact that FireWire was designed as an expansion bus – it has the same characteristics as PCI, AGP, ISA, PCMCIA, CardBUS etc – it’s a connection port designed to have all kinds of hardware plugged into it, and that hardware gets very low, and very fast access to the system memory, processor etc. FireWire was designed to be faster than USB, until USB2 came along and usurped it anyway.

Talking of USB, I should add why this attack does not work on the USB port – The USB bus was designed to be a peripheral bus, so like serial ports, parallel ports, PS2/AT etc. It’s designed to allow a bunch of devices to communicate with each other (like a network) – not to allow devices access to the hardware.

A practical way to use this exploit.

The simplest attack is to prepare a laptop with tools designed to implement this attack vector, and then connect it to the target machines FireWire port. There are several tools available which demonstrate this attack, for example winlockpwn which will bypass a Windows XP locked screen saver, or bioskbsnarf which will return the BIOS keyboard buffer (and thus your Bitlocker pin). Simply, as this attack allows the rogue device to access any memory it likes, it can subvert any system process, and thus install, or modify code on demand. Of course, the machine has to be running an OS for this to be useful.

There have been other reported tools which can be run from an appropriately hacked iPOD (thus negating the need for a laptop at all), and also ones which reportedly can break into things like Pointsec Full Disk Encryption (when used without pre-boot authentication).

Defending against this attack.

The most obvious defense that comes to mind is to buy/use laptops without FireWire ports, but unfortunately there are gadgets like ExpressCard FireWire cards which give you a simple way of adding a FireWire port to any laptop with a PCMCIA or ExpressCard slot. No, the port does not have to be built in.

To mitigate this attack, you can do a few things:

• Use a machine where you can prevent FireWire devices being used, and prevent the OS from loading a FireWire driver on demand. This is probably only possible with the Linux/BSD based OSs, certainly Windows has a habit of loading the drivers on demand
• Seal the ports up with epoxy to prevent people plugging things in – remember to seal up ports which could be used to add a FireWire controller (like PCMCIA/Expresscard)
• Use Full Disk Encryption with pre-boot authentication to prevent the machine booting up (and thus being vulnerable to this attack), and don’t use suspend/lock screen when leaving your machine unattended.

Remember – a running OS with accessible ports (or the ability to add ports) is vulnerable, so that’s the situation we need to avoid.

Can we ever resolve this “weakness”?

This attack is particularly difficult to “cure”, as the specification, and devices which use FireWire require DMA to work – it’s integral to the way FireWire was designed, abuse of this requirement is the cause of these woes, so until we see a radical change in the specification the situation is unlikely to improve. In the mean time, full disk encryption with authentication, and hibernation rather than suspend, or “locked screen” modes will keep you safe from “FireWire snarfing”.

Regulatory and compliance issues

It’s an interesting question to consider – if you lost an “encrypted” machine, that was running without pre-boot authentication, is this attack practical enough to cause you problems with data disclosure laws? Many people would argue that the Windows Login screen provides sufficient protection, but if that can be bypassed by simply plugging in a FireWire card and running winlckpwn, are you sufficiently protected?