Beyond The CPU: Cheating Hardware Based RAM Forensics

We all know that any software-based system compromise detector can always be cheated if malware runs at the same privilege level as the detector (usually both run in kernel mode). This is what I call Implementation Specific Attacks (ISA). Because of that, mankind has tried to find some better, more reliable ways for analyzing systems, which would not be subject to interference from malware…

And we all know what we’ve come up with as a solution – hardware based devices for obtaining the image of volatile memory (RAM), usually in the form of a PCI card. As far as the PC architecture is concerned, probably the first two papers in this area are those about Tribble and CoPilot. As an alternative to expensive dedicated PCI cards, one can also use a FireWire bus, as it has been described by Maximillian Dornseif at el., and later by Adam Boileau.

The point is: once we get the memory image, we can analyze it for signs of compromises on a trusted machine or we can have the PCI device to do some checks itself (like e.g. CoPilot does).

The whole idea behind hardware based RAM acquisition is that the process of reading the memory is using Direct Memory Access (DMA) to read the physical memory. DMA, as the name suggests, does not involve CPU in the process of accessing memory. So, it seems to be a very reliable way for reading the physical memory…

But it is not! At least in some cases...

Next month, at Black Hat DC, I will be demonstrating how to cheat hardware based memory acquisition on AMD based systems. In other words, I will be showing that the image obtained using DMA, can be made different from the real contents of the physical memory as seen by the CPU. Even though the attack is AMD-specific, it does not rely on virtualization extensions. Also, the attack does not require system reboot. Nor does it require soldering ;)

I have tested my proof-of-concept code against a FireWire-based method of memory acquisition, using tools from Adam Boileau’s presentation.

I wanted to test it also against some PCI cards, but it turned out, that for an ordinary mortal person like myself, it is virtually impossible to buy a sample of a dedicated PCI card for memory acquisition… E.g. the Tribble card is still unavailable for sale, according to its author, even though the prototype has been build in 2003... BBN, the US company known for doing lots of project for the US government, apparently has a prototype (see page 45) of something similar to Tribble, but is not willing to discuss any details with somebody who is not involved in a project with the US government... Finally, Komoku Inc., whose main customers, according to the website, are also US government agencies, also rejected my inquiry for buying a sample of CoPilot, claiming that the device "is not generally available right now" ;)

Anyway, even though I was able to test the attack only against FireWire based method, I’m pretty confident that it will work against all other devices which use DMA to access the physical memory, as the attack itself is very generic.

See you in DC!

Towards Verifiable Operating Systems

Last week I gave a presentation at the 23rd Chaos Communication Congress in Berlin. Originally the presentation was supposed to be titled "Stealth malware - can good guys win?", but in the very last moment I decided to redesign it completely and gave it a new title: "Fighting Stealth Malware – Towards Verifiable OSes". You can download it from here.

The presentation first debunks The 4 Myths About Stealth Malware Fighting that surprisingly many people believe in. Then my stealth malware classification is briefly described, presenting the malware of type 0, I and II and challenges with their detection (mainly with type II). Finally I talk about what changes into the OS design are needed to make our systems verifiable. If the OS were designed in such a way, then detection of type I and type II malware would be a trivial task...

There are only four requirements that an OS must satisfy to become easily verifiable, these are:

1. The underlying processors must support non-executable attribute on a per-page level,


2. OS design must maintain strong code and data separation on a per-page level (this could be first only in kernel and later might be extended to include sensitive applications),


3. All code sections should be verifiable on a per-page level (usually this means some signing or hashing scheme implemented),


4. OS must allow to safely read physical memory by a 3rd party application (kernel driver/module) and for each page allow for reliable determination whether it is executable or not.

The first three requirements are becoming more and more popular these days in various operating systems, as a side effect of introducing anti-exploitation/anti-malware technologies (which is a good thing, BTW). However, the 4th requirement presents a big challenge and it is not clear now whether it would be feasible on some architectures.

Still, I think that it's possible to redesign our systems in order to make them verifiable. If we don't do that, then we will always have to rely on a bunch of "hacks" to check for some known rootktis and we will be taking part in endless arm race with the bad guys. On the other hand, such situation is very convenient for the security vendors, as they can always improve their "Advanced Rootkit Detection Technology" and sell some updates... ;)

Happy New Year!