Rutkowska on Cheating Physical Memory Acquisition: Details

Thomas Ptacek | March 2nd, 2007 | Filed Under: Defenses, New Findings, Uncategorized

A little birdy floated me a copy of Joanna’s slides off the CD (sorry, Jeff; we owe you one free Black Hat talk this year). Here are the details:

The AMD64 PCI/HyperTransport Northbridge (the interface between the CPU, memory controller, and PCI) has CSRs that map physical address ranges to I/O address space (that is, the range of memory addresses that are serviced by peripherals, not DRAM). This mapping is implemented in between the bus and the memory controller, and not mediated by the CPU.

Which is to say, you can program the AMD64 Northbridge to remap physical addresses for devices on the PCI bus. In particular, you can map any physical address back to I/O space, so that when your Firewire OHCI controller tries to read it, the Northbridge bounces the request back out to the PCI bus.

So, it’s straightforward to see how this impacts Firewire/PCI forensics: the processor has documented features that allow you to shut off regions of physical memory to PCI devices.

All of Joanna’s attacks rely on this trick:

• You can halt the target of a memory acquisition by mapping regions of memory to invalid I/O destinations. This deadlocks the target. This is a “DOS Attack”.

• You can feed dummy data (all 0xFFs —- the data isn’t under the control of the attacker) back to the acquisition device by mapping regions of memory to valid but meaningless destinations. This is a “Covering Attack”.

• You can feed user-controlled data back to the acquisition device by mapping regions of memory to devices that have their own peripheral memory, which you overwrite with your “innocuous” data. This is a “Full Replacement Attack”, but I think “Full Replacement” is a clumsy name, so I’m going to call it a “Shadowing Attack”.

So, this is a fun talk. But Rutkowska can take this farther, and should.

For starters, “DOS”, “Covering”, and “Shadowing” isn’t the most interesting breakdown. All three are variations on the same game-over theme: if you can reliably intercept memory accesses by a forensic acquisition device, that’s game over.

The next thing to flesh out is, what are the various means of getting between the acquirer and physical memory? Here’s a possible breakdown:

• Detection Attacks tip malware off to the presence (or activity) of an acquiring device. Once tipped off, malware can submarine itself in a variety of ways (latently infecting peripherals, going to disk temporarily, dumping itself to swap, or diving back into userland and re-exploiting the original kernel vector to get back in, etc) to avoid an active memory scan.

• Jamming Attacks interfere with an acquiring device’s ability to get at memory at all. For instance, ring 0 malware controls the Firewire OHCI CSRs and can disrupt DMA requests; if your acquiring devices expose CSRs, malware can use them to evade detection.

• Shadowing Attacks are what Rutkowska seems to have presented, but this talk only seems to have considered the AMD64 PCI/HT MMIO tables. Obviously there are others, probably even on the AMD64. On Intel, the most obvious place to start looking is in the TXT/LT extensions, which were designed explicitly to combat malicious acquisition devices.

• Frontal Attacks a-splode the acquiring device itself, because how likely is it than at any forensics company has implemented a device that is customized enough to be hermetically sealed from ring 0 code that controls its bus, and simultaneously free of implementation bugs?

• Content Attacks deliberately obfuscate memory to foil superficial analysis techniques; for instance, the open-source code I’ve seen tends to sweep through memory looking for EPROCESS blocks to find page directory base pointers, and then assuming the page hierarchies they find are valid.

I’d also like to see some consideration given to countermeasures. For instance, Firewire read access comes with Firewire write access, and Firewire write access comes with code execution. Can’t a smart acquisition device (and I concede there are none) reprogram the Northbridge temporarily to get around this? Is there another cat-and-mouse game here, too? If a pristine system does allow us to reliably execute code (for instance, by detouring interrupt vector code), can’t we detect it if malware prevents us from doing that?

Rutkowska has made a really excellent point with a clever talk: PCI DMA-driven access to physical memory is not a foolproof forensics technique. “Purely theoretical” and “hard core” are words I’ve seen describing this talk, but —- and I mean this as a compliment —- it’s not that hard; I’m guessing you can show yourself how this works using Windbg and a firewire card inside of an hour. Malware authors will use these techniques.

I’m looking forward to rev 2.0 of this talk.