Hacker Defeats Hardware-based Rootkit Detection

Manequintet writes "Joanna Rutkowska's latest bit of rootkit-related research shatters the myth that hardware-based (PCI cards or FireWire bus) RAM acquisition is the most reliable and secure way to do forensics. At this year's Black Hat Federal conference, she demonstrated three different attacks against AMD64 based systems, showing how the image of volatile memory (RAM) can be made different from the real contents of the physical memory as seen by the CPU. The overall problem, Rutkowska explained, is the design of the system that makes it impossible to reliably read memory from computers. "Maybe we should rethink the design of our computer systems so they they are somehow verifiable," she said."

Comments

Re:I thought this was invalid anyway

[Score Whore]

An "ultrathin hypervisor" as some call it is a very tiny OS wrapper. The wrapper does indeed have negligible effect on the system - about as much effect as, say, running a small background process.

Like I said, if you are going to do nothing, then sure, you'll have a hard time detecting it. But if it does something, like keylogging or sending spam, then it'll have measurable effects.

Wrong -- "measurable" in this sense may not be so measurable. The clever malware could fool the system timer to be a little bit off (say, 0.1%), so that it hides its tiny footprint in the timer. Thus, any attempt to query the timer would just return the expected result.

Not wrong. My timer is on my wrist. There's another one on the wall. Neither one is attached to my computer. There is another on my network for the specific purpose of keeping track of the slew in my various systems' clocks. Additionally if you start screwing with my system clock, other systems on my network would see this behavior in fucked up timings in the local system's network stack. If your hypothetical malware is slowing my system timer to hide its consumption of system resources, then keepalives would be arriving at remote hosts late. Also there would be drift in the system clock vs. my gps receiver.

Then there are devices that have physical clock rates. Serial ports, PS/2 ports, sound cards, video cards, etc. You can go into a tight loop for X number of intervals of playing a known number of 44.1 Khz samples to your sound card. If you used to be able to get through 250 million interations of the loop and now you can get through 247 million iterations of the loop, then you know something is consuming resources on your system. And if you really want to measure the impact of the malware then make your loop perform privileged operations so that they must be virtualized.

And there is the fact that you could compare two clocks, the mobo's time of day clock and the CPU's cycle clock. If you screw with them both you'll see all sorts of bad behaviors. If you don't, then you can compare the relative speed of the two to see the loss due to malware.

Finally the malware has to live somewhere in system RAM. It can't allow itself to be over written. The original OS knows how much RAM is supposed to be there, so just consume all memory. When it attempts to swap out to a local hard drive, go ahead and fill that up too.

There's a lot of hyperbole and sensationalism about virtualized root-kits.

Re:AACS "Improvement"

[Phil Resch]

Well, no. Not entirely.

Under normal conditions, that's correct. If a player has loaded the key into memory somewhere in order to use it, you can probably isolate the location in memory and retrieve the key. Which is what has been done to retrieve the AACS keys.

But the pathological case, the case dealing with rootkits, changes the game. How do you track the contents of your physical memory? Typically, through OS mechanisms. What happens if a rootkit (or a software media player using rootkit technology) subverts the OS mechanisms? You can't be assured of reliably tracking the contents of memory any more; maybe your OS is LYING to you! What is really in memory is not what you're being told is in memory, and maybe you can't find that key any longer.

Which brings us back to the article. Direct Memory Access (DMA) is a way of taking the responsibility for managing physical memory access (reading, writing, whatever) away from the processor and moving it to some other place in hardware (presumably some place that you can trust). And that's what hardware-based rootkit detection is about. Use hardware with DMA (which you trust) to access memory instead of letting the processor do the work and relying on the OS to tell you the truth.

The problem is that the way computers are currently designed, there's no way of starting DMA without having to talk to the processor (by way of the OS) first. Your DMA hardware has to ask "Hey, can I access memory?" and the OS has to say "Sure thing! You do it, and we won't bother the processor any more!"

But if the (subverted-by-a-rootkit) OS has a vested interest in you NOT being able to get true results using DMA, well, what are you going to do? The OS will just interfere. That's why Rutkowska is suggesting a direct, non-subvertable hardware port that you can jack into to use DMA without having to go through the OS first.