Weekly Edition
Return to the Security page
| |||||||||||||
Attacking full-disk encryption with InceptionWhen using whole-disk encryption, it's sometimes tempting to be less concerned about attacks requiring physical presence. After all, putting a laptop to sleep is quite convenient, even though attacks like "Evil Maid" or "Cold Boot" are possible. A more recent attack just adds another worry to that list. Inception is a tool released in 2011 that uses Firewire direct memory access (DMA) to access the memory of a sleeping (or simply powered-on, but locked) system. While it is an an older tool, Inception recently got a notoriety boost from Cory Doctorow at Boing Boing, which is where I came across it. It is a rather interesting attack, and one that isn't really exploiting a bug. In order to facilitate high-speed transfers, Firewire (aka IEEE 1394) requires the availability of a DMA mode. DMA allows the Firewire controller to directly access system memory, bypassing the CPU. While removing the potential bottleneck of the CPU does make transfers faster, it also opens up the contents of memory for any Firewire device to inspect or modify. This is the same memory that contains various things of interest, including the code to check passwords. It is the password-checking code that Inception targets. When the incept program is run, it will patch the Linux, Windows, or Mac OS X code running on the system such that any password can be used to log in. After that, one can log in as root (or Administrator) without need for the password—the system is fully compromised. Since the patching is in memory only, though, the change disappears at the next reboot, which may make it more difficult to detect. Inception doesn't require a Firewire interface on the targeted system, just some way to add one (e.g. PCMCIA, ExpressCard). Typically, the system will detect the Firewire device being added and helpfully install the drivers needed. The attacker's machine, which is attached to the victim over the Firewire interface, then sends commands to enable DMA mode. From there, the program looks for signatures of password authentication modules and patches any it finds. There are, of course, other things one can do with access to the memory, including dumping its contents for use later on. The system memory may well contain information of interest, for example credentials of various sorts. Patching other parts of the operating system are possible as well, and the incept program has support for using custom signatures and patches. Inception is useful for more than just attacks, as it can be used to help analyze any running system—one that has been compromised for example. The attack code runs on Linux or OS X systems. It requires Python 3 and libforensic1394. Unsurprisingly, there are some caveats. Targets with more than 4G of RAM may not be attacked reliably because DMA is limited to the low 4G and the code of interest might be loaded higher up. In addition, certain OS X targets may repel the attack by disabling DMA under certain circumstances (like sleeping). One obvious mitigation for Linux is to disable the Firewire drivers for systems that aren't using them. One could, instead, disable Firewire DMA when the drivers are loaded, but if Firewire is actually being used, that will clearly impact performance. Inception serves as a nice reminder that a powered-on system is vulnerable to many "physically present" kinds of attacks—even if the disk is encrypted (Log in to post comments)
Use an IOMMU Posted Jan 10, 2013 2:34 UTC (Thu) by skissane (subscriber, #38675) [Link]
The solution is to use an IOMMU, such as Intel VT-d. Then you can selectively allow DMA devices access to only the regions of memory they are supposed to access, and block them from reading or writing any other memory. Protects against both this attack, and several others.
Of course, that's assuming you have hardware with an IOMMU, and your OS knows how to configure and enable it.
Use an IOMMU Posted Jan 10, 2013 10:11 UTC (Thu) by epa (subscriber, #39769) [Link]
I'm amazed that the design of Firewire allows DMA mode to arbitrary addresses to be chosen over the wire. Most SCSI interface cards support DMA too, but that doesn't mean your hard disk gets involved in the details of which address range to write to. (Or does it?)
It does Posted Jan 10, 2013 14:35 UTC (Thu) by renox (subscriber, #23785) [Link]
AFAIK without IOMMU, any DMA-capable device can do the same as this 'firewire' hack, provided you can control the device..
It does Posted Jan 10, 2013 16:38 UTC (Thu) by epa (subscriber, #39769) [Link]
I thought that the 'DMA-capable device' was the PCI or PCI Express card in your motherboard. (Obviously if the attacker can plug in any card to a PCI slot you've already lost.) But you are saying the DMA-capable device is actually the hard disk connected to the PCI card, which gets to choose all by itself which address range to write to?
It does Posted Jan 10, 2013 21:29 UTC (Thu) by renox (subscriber, #23785) [Link]
I'm not sure, what would prevent it?
It does Posted Jan 11, 2013 10:10 UTC (Fri) by epa (subscriber, #39769) [Link]
What I imagined was this: the SCSI controller (being a DMA-capable device attached to the PCIe bus) sets up a DMA transfer using an address it has chosen. The SCSI controller then transfers data to and from the disk over the SCSI bus - this using the SCSI protocol and not related to host addresses in any way. On receiving data from the disk, the controller DMAs it into memory.
But you are saying that the *disk* gets to choose which part of the host's memory to write to, and organizes the DMA itself?
It does Posted Jan 11, 2013 12:24 UTC (Fri) by cladisch (✭ supporter ✭, #50193) [Link]
> But you are saying that the *disk* gets to choose which part of the host's memory to write to
Yes; the disk gets told by the disk driver the address which it should write to.
> and organizes the DMA itself?
The disk device just sends a packet with a specific address to the host.
This address usually works similar to the port number in TCP/IP, i.e., the controller writes the packet into a buffer configured by the driver, and the host's FireWire software stack uses the address to determine which driver/application gets to handle the packet.
However, as an optimization, FireWire controllers can be configured by the driver to handle certain packets from certain devices differently, by writing them to the physical memory address specified in the packet itself.
It does Posted Jan 11, 2013 16:19 UTC (Fri) by epa (subscriber, #39769) [Link] The disk device just sends a packet with a specific address to the host.Surely not - the disk sends a packet to the SCSI controller, and then the SCSI controller writes into the host's memory. (Unless this is just a question of terminology) However, as an optimization, FireWire controllers can be configured by the driver to handle certain packets from certain devices differently, by writing them to the physical memory address specified in the packet itself.I see - that is the root of this vulnerability. Clearly if devices can be plugged in externally, that optimization needs to be disabled.
It does Posted Jan 11, 2013 16:36 UTC (Fri) by etienne (subscriber, #25256) [Link]
> But you are saying that the *disk* gets to choose which part of the host's memory to write to, and organizes the DMA itself?
Well, if you are queuing different reads from the disk, and the disk decides himself in which order it does them, it will have to synchronise to the DMA controller in maybe complex ways to write the right sector at the right place...
No it doesn't Posted Jan 12, 2013 1:13 UTC (Sat) by butlerm (subscriber, #13312) [Link]
There isn't a SCSI interface on the planet where a SCSI disk instructs the SCSI host adapter which host memory address to write to. Nor an IDE/ATA/SATA one for that matter. That would be insane.
No it doesn't Posted Jan 14, 2013 10:14 UTC (Mon) by etienne (subscriber, #25256) [Link]
But a hacked SCSI adapter can ignore the address of the transfer given by Linux and instead do a DMA anywhere.
Same for a hacked IDE adapter, and mostly for PCMCIA/CardBus card accessible on a lot of PC without opening the box.
No it doesn't Posted Jan 14, 2013 11:19 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
Yes, if you take over some device directly attached to the memory or PCI bus of a machine you can access anywhere in RAM
with firewire this doesn't take hacking the card, it's a normal mode of operation.
No it doesn't Posted Jan 16, 2013 13:25 UTC (Wed) by epa (subscriber, #39769) [Link] There isn't a SCSI interface on the planet where a SCSI disk instructs the SCSI host adapter which host memory address to write to. Nor an IDE/ATA/SATA one for that matter. That would be insane.Right. But apparently Firewire does have that design flaw?
No it doesn't Posted Jan 17, 2013 16:39 UTC (Thu) by cladisch (✭ supporter ✭, #50193) [Link]
> > There isn't a SCSI interface on the planet where a SCSI disk instructs the SCSI host adapter which host memory address to write to.
> > But apparently Firewire does have that design flaw?
The three transport protocols where SCSI can use some form of remote DMA are FireWire, InfiniBand, and iWARP.
It does Posted Jan 11, 2013 10:23 UTC (Fri) by renox (subscriber, #23785) [Link]
No, I just forgot about the SCSI distinction between the disk and the controller.
Attacking full-disk encryption with Inception Posted Jan 10, 2013 15:25 UTC (Thu) by jmspeex (subscriber, #51639) [Link]
Interesting. It seems like this would also defeat all the "secure boot" stuff that checks module signatures.
I'm puzzled... Posted Jan 10, 2013 15:28 UTC (Thu) by cruff (subscriber, #7201) [Link]
How does this work? Usually the DMA registers of an interface have to be programmed from the host side, not the device side. Even RDMA capable interfaces require the host to set things up before the remote side can initiate a transfer. Are they relying on known bugs in the Firewire drivers?
I'm puzzled... Posted Jan 10, 2013 15:35 UTC (Thu) by apoelstra (subscriber, #75205) [Link]
> How does this work? Usually the DMA registers of an interface have to be programmed from the host side, not the device side. Even RDMA capable interfaces require the host to set things up before the remote side can initiate a transfer. Are they relying on known bugs in the Firewire drivers?
I wondered about this too. Maybe because Firewire uses DMA for file transfers, it needs more freedom in what memory it accesses?
Normally when I use DMA, it's for interfacing with a specific chip (media decoder, USB host, etc), so there's a known, fixed memory location that needs DMA -- one that isn't used by anything else as long as the driver is loaded.
I'm puzzled... Posted Jan 10, 2013 16:01 UTC (Thu) by cladisch (✭ supporter ✭, #50193) [Link] Even RDMA capable interfaces require the host to set things up before the remote side can initiate a transfer. The protocol used for FireWire disks (SBP-2) does use remote DMA (but calls it “physical DMA”). The FireWire code has to explicitly enable RDMA for each device it trusts. However, handling SBP-2 transfers in software is not implemented (yet), so RDMA is enabled for any device that is a mass storage device, or just claims to be one.
Attacking full-disk encryption with Inception Posted Jan 11, 2013 18:43 UTC (Fri) by intgr (subscriber, #39733) [Link]
All modern peripheral interfaces can do DMA transfers -- SATA, PATA, PCI, USB, FireWire and probably others. Why is FireWire always singled out as allowing full access to host memory? Are other interfaces inherently protected against this attack? (Apart from the loophole that allows installing a FireWire controller as a PCI device)
Attacking full-disk encryption with Inception Posted Jan 11, 2013 19:30 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
As I understand it, all the other devices have the device driver/controller card setup and start the DMA
With Firewire, the device sets up and starts the DMA
so the exploit DMA on other devices, you need to hack the firmware of the controller card to have it do something other than what the device driver expects it to.
But with Firewire, you only need to hack the firmware of the device you are plugging in (and since you can completely control that device, this is rather easy)
In terms of risk, Firewire is more like exposing the PCI bus for external things to plug into.
Attacking full-disk encryption with Inception Posted Jan 12, 2013 0:21 UTC (Sat) by luto (subscriber, #39314) [Link]
Firewire has a particularly dumb design, especially for something meant for use *outside* the computer. The kinds of transfers used for SBP-2 are "asynchronous requests", which are commands like "write this data to this address". The address is a 48-bit number.
OHCI (i.e. pretty much every firewire controller) figures out what to do with an asynchronous request by inspecting its address. If the target address is below 0xffffffff, then the request is turned into phsyical DMA (but only if this feature is on). If the target address is above 0xffffffff, then the request is forwarded verbatim to the driver, and the driver can do whatever it wants. (The data is DMA'd to a normal DMA buffer, so the driver might need to do another copy.)
IMO the solution has two parts:
1. Turn off physical DMA. Rearrange the SBP-2 driver to use high (>0xffffffff) addresses and add the appropriate memcpys. Performance drops a little bit, but the security problem goes away.
2. (Only if you want to be super fancy) Rig up the ohci driver to operate in a different mode if to can assign itself a unique iommu domain and if the specific hardware supports a physical dma cutoff that's different from 0xffffffff: Divide the low address space into two regions. DMA used internally by the driver ends up at, say, iova < 2G. Memory mapped for "physical DMA" ends up with 2G < iova < 4G. Program the card to allow firewire-initiated physical DMA only between 2G and 4G. Then have the SBP-2 driver ask the core to "map" its buffers. If supported (in this iommu mode), the buffers will be mapped to iovas 2G and 4G. If not, then the buffers won't be mapped for DMA at all; instead they'll be "mapped" above 4G and something will emulate the DMA.
More info here:
http://comments.gmane.org/gmane.linux.kernel.firewire.dev...
I'm unlikely to do this myself any time soon.
|
|||||||||||||