Firewire and similar DMA attacks

Kevin Day thekevinday at
Wed Mar 12 06:59:38 PDT 2008

On Tue, Mar 11, 2008 at 9:58 PM, Chris Buxton <cbuxton at> wrote:
> On Mar 11, 2008, at 4:21 PM, Kevin Day wrote:
>  > On Tue, Mar 11, 2008 at 3:34 PM, Chris Buxton
>  > <cbuxton at> wrote:
>  >> I've been reading about the effectiveness of attacks from devices
>  >> with
>  >> DMA access such as Firewire mass storage devices.
>  >>
>  >>
>  >> The article states that this affects Mac, Windows, and Linux machines
>  >> with FW ports, because the device that is granted DMA access through
>  >> the FW interface is given read/write access to all memory. It can
>  >> then
>  >> apparently determine the OS type and start doing things to memory,
>  >> outside of the control of the CPU and therefore of the kernel. This
>  >> includes reading encryption keys, writing to executable memory, etc.
>  >> The very flexibility of Firewire to hook up different machines, with
>  >> different operating systems, and have one see the other as a mass
>  >> storage device appears to be one source of the risk.
>  >>
>  >> Does anything in the hardened toolchain, kernel with grsec, etc.,
>  >> protect against this?
>  >>
>  >> Chris Buxton
>  >> Professional Services
>  >> Men & Mice
>  >> --
>  >
>  > Grsecurity would be the way to fix the problem, but...
>  >
>  > The article above does not directly say anything about linux being
>  > effected, it only points in the general direction.
>  > Looking further I found:
>  >
>  > After reading the notes available on the page, the security flaw is in
>  > the hardware. As a result, your solution is to physically remove the
>  > firewire devices from the system
>  But then you run into problems with hotplug, if someone plugs in a hot-
>  pluggable firewire controller (e.g. cardbus). Of course, for an
>  appliance, you can simply disable hotplug.
>  (Someone actually demonstrated using a cardbus or pc-card firewire
>  controller to take over a Windows XP laptop.)
>  > or have the kernel disable DMA for
>  > the firewire.  With DMA, the hardware is able to ignore the OS and
>  > talk straight to memory, such that the OS can do nothing.
>  And that's the basic problem. It's not so much a firewire problem as a
>  DMA problem, and the fact that Firewire requires (mandates, in the
>  standard, iirc) DMA.
>  > This also begs the question on some sort of exploit via a wireless
>  > firewire device! Are there any wireless firewire devices?
>  No, there are no wireless firewire devices, nor wireless USB. Besides,
>  a wireless device likely wouldn't gain any real benefit from DMA.
>  > I don't
>  > really use firewire, I prefer e-Sata (goooo! my almost fiberchannel
>  > speeds go!).
>  e-Sata has the same issue, if a device with a CPU can fool the target
>  into thinking it's just an e-Sata mass storage device. Probably a bit
>  harder than with Firewire, which was designed to be able to connect
>  computers, but probably still possible. Same goes for USB 2, probably.
>  > Of course, there should be a way to mask the true hardware from the
>  > device with DMA such that only certain blocks of memory are visible to
>  > the device with DMA. Linux Bios anyone?
>  Doing so with Firewire is apparently not really possible.
>  Chris Buxton
>  Professional Services
>  Men & Mice

I believe the issue is that most people do not have direct access to
the box's insides, but every external port might be available in a
public machine.
Alternatively, somebody could walk into your environment plug in an
external device, firewire and not look suspicious like the would if
the were pulling the machine apart to plug in a PCI card.
And unlike the live-cd issue, this can be done without rebooting the
machine so no other flags or alarms will probably be set.

These arguments just sound to me like saying that because anybody
could get into a computer (via physical world or remote access) then
compile a program (or bring a binary) that explicitly memory leaks to
gain root access or access to memory, then it is not a problem at all
because anyone can do it.  And of course users may need to be able to
compile and users may need to be able to run arbitrary programs, so
its clearly not a security problem.
Of which these can actually be solved by SSP and grsecurity's only
allow trusted to execute in non /bin:/usr/bin/: etc.. binaries (or

Next is the case that with open-source, people can use their systems
in almost anyway/anywhere they want to.  There are people who need
insane security precautions and there are people who will give their
system access to people they cannot trust, without giving them
physical access to the internals of their machine.

For those that need these security practices, the method should be
available.  This is open-source, all we need is a flag to enable for
those who need it and a disable for those who need to not have it.

Kevin Day

More information about the hlfs-dev mailing list