Hacker Defeats Hardware-based Rootkit Detection 126
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."
AACS "Improvement" (Score:5, Interesting)
Isn't this exactly what HD-DVD / Blu-Ray players need to prevent the AACS keys from being stolen? Just last week there was a story saying something like "PC-based movie players are inherently crackable, because the key has to be in main system memory for at least a brief instance, and then we can copy it." Now, this lady says there are methods to prevent anyone from truly reading what is in RAM. I don't understand.
Re:I thought this was invalid anyway (Score:1, Interesting)
I've done a fair amount of hardware debugging, one of the problems reading memory directly is that the CPU kind of dictates how and where it is used, potentially on a page by page basis and 4k pages aren't really that much. There are great logic analyzers that will decode instructions in memory and do all the stuff you'd expect, but you still need to know where the right pages are mapped. So what do you do? You ask the CPU, which also means that malware could lie. There is usually a lot more contiguous memory than you might think and there are hardware limitations on some platforms as to how memory can be paged and fragmented but the bottom line is you need something that the CPU has to really know where the memory you think you're reading really is. I would guess that a hardware malware detector wouldn't be terribly useful without some integration to the CPU. I don't have a PCI spec in front of me but I'd bet that hardware can't arbitrarily read any memory it wants without the CPU allowing it. (Shit, think of the firmware malware possibilities if it could, more importantly a PCI device could have it's own memory to hide in that the CPU cannot see..)
Drivers and hardware devices can DMA in and out of memory, but they lock a specific location and they always tell the CPU. The CPU owns memory, that's the rule and unless it gives ownership to some other device (such as it might during a DMA) then you have to involve the CPU anytime you wish to decode memory.
I respect that hell out of Joanna, I kind of think her 2 big findings were a bit of PR though. The Blue pill one was kind of good because a lot of people have virtualization hardware that don't know it but the short of it was if you have v14n hardware you need to use it and at least install some minimal hypervisor so a malware doesn't. This seems like more of the same; if I get my malware in there deep enough, I can really confuse most attempts to debug it. Viruses have had anti-debugging technologies since the 80's. It's kind of the classical host debugging problem, you really need to do certain types of debugging from a different host, even then there are hooks you need on the host machine (unless it has jtag or something) and those hooks can be corrupted. I don't know that this is news exactly.
There's already one solution available (Score:5, Interesting)
You can already do this, with many common CPUs. It's called JTAG. In short, it allows you to control the CPU directly, so that you can do exactly what Ms. Rutkowska proposes. That includes by-passing the caches and getting direct access to memory.
JTAG is what embedded people use to port an O.S. to a new hardware platform. And to debug really tough kernel problems. It beats the snot out of printks anyday. And there are certain sections of boot-code and kernel code where it is extremely difficult and annoying to develop without JTAG.
There are two immediate problems with JTAG however. The first is that not all CPUs support it. Believe it or not, I've met CPU designers who have never heard of JTAG (and this is usually a clue that they don't know what the heck they are doing).
The second problem is that some CPU manufacturers consider the JTAG interface proprietary. Intel is one (there's only one JTAG debugger available for x86, and it will cost you between $5,000 - 15,000 depending on what you get). That is absolutely silly, as these can be built for well under $500.
Why they keep the JTAG API interface proprietary is beyond me. I have yet to hear a non-lame excuse yet.
But in any case, the point is that this problem has already been solved. It's surprising to me that anyone seriously doing forensics wouldn't be using JTAG already, for the reasons that Ms. Rutkowska suggests.
Re:Trying to have her cake and eat it too? (Score:3, Interesting)
Obviously (1) is really no defense at all because it only needs to be done once and then it is "free" and (2) is deceptively difficult to implement in a fool-proof manner that does not incur large costs on a per-site basis -- it requires an external time source *and* an external performance measurement system because any time data entering the compromised machine (say via NTP) can itself be twiddled to hide timing variations. The obvious method of such a test would be to run a (potentially) trapped instruction that normally takes microseconds but when trapped takes milliseconds. Run it in a loop 100,000 times and the difference will be discernible to a human watching it - but what if the vm is smart enough to recognize such an automated test and temporarily disable the trap for the duration of the test? Not an easy test to implement, not to mention that anytime you have to get a human involved the deployment costs sky-rocket. What is to prevent that rootkit-VM (the one that twiddled the registers in the first place) from faking out any attempt by the legit OS to read those registers? Isn't that point of a rootkit-VM, to fake out any parts of the system that need faking out so that the rooted OS can't detect it?