Slashdot Mirror
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."
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.
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.
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.
Issues:
.001% of admins who run with highly sensitive data and audit every line of code going into their systems, this is a definite threat that they should be concerned about detecting. And they're pretty difficult to detect. And they're something new and special, so they're the Next Big Thing.
The CPU is idle. A lot. The rootkit could quite easily only run itself when the CPU would otherwise be in nops or a delay loop. It's essentially impossible to use 100% of the CPU, because something, somewhere in a modern OS is generally going to run a few nops or go into a known loop state, at which the malware could just overwrite the nops or delay instructions and not delay the system at all. So your method isn't terribly great.
Now, calling privileged instructions as you mention is a brilliant way of sensing the malware, as it's unavoidable that the malware must handle most privleged instructions acting as a virtual machine, and then it'd definitely be losing clock cycles.
Unless you're listening to the samples and counting every one the rootkit could just discard enough of the calls to make the clock rate appear the same.
The OS has no idea if the virtual machine is swapping for it. And unless you're filling the RAM with random data and then reading it back + timing it memtest86 style, the VM could just discard all the memory you allocate.
Yes, there is a ton of hyperbole and sensationalism. Virtualized rootkits are among the least common threats currently on the internet and all users and 99% of admins need not worry about them, as they have much more important things to be concerned about. But for the
This sort of thing is why security people sometimes act so devoid of hope.
Yes. The ability to directly access memory space by address from a FireWire connection is a totally inappropriate "feature" on a machine with an operating system. It's intended for embedded system debugging and remote device control. The FireWire interface hardware has it off by default. Windows has to explicitly turn it on. Despite the fact that, as far as I know, that feature is never used for anything legitimate.
And yes, it's broken in Linux. I just looked at the hardware spec (see figure 5-28) and the source code for "fw-ohci.c", and there it is:
That line says "external FireWire packets can access any physical address below (0x10000 << 16)", or, in other words, the first 4GB of memory. Apparently this security hole hasn't been upgraded for 64 bits yet, although the hardware supports a 48-bit memory address. Note the lack of any comments in that area. That one bit opens up a huge security hole, one known for three years, and nobody has fixed it.
I'd suggest changing that value to 0, which turns this "feature" off.