Slashdot Log In
Hacker Defeats Hardware-based Rootkit Detection
Posted by
CmdrTaco
on Sun Mar 04, 2007 11:00 AM
from the immovable-object-vs-unstoppable-force dept.
from the immovable-object-vs-unstoppable-force dept.
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."
Related Stories
[+]
VM-Based Rootkits Proved Easily Detectable 128 comments
paleshadows writes "A year and a half has passed since SubVirt, the first VMM (virtual machine monitor) based rootkit, was introduced (PDF), covered in the tech press, and discussed here. Later Joanna Rutkowska made news by claiming she had a VMM-based attack on Vista that was undetectable — a claim that was roundly challenged. Now in this year's HotOS workshop, researchers from Stanford, CMU, VMware, and XenSource have published a paper titled Compatibility Is Not Transparency: VMM Detection Myths and Realities (PDF) showing that VMM-based rootkits are actually easily detectable."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I thought this was invalid anyway (Score:4, Insightful)
ie remove the drive/devices and check them all.
Re:I thought this was invalid anyway (Score:5, Insightful)
Parent
Re: (Score:2)
That's still no guarantee... (Score:2)
That presumes that the replacement hardware hasn't had its BIOS and/or firmware flashed with malware itself. Do they checksum the ROMs and compare that against what the vendor tells them? Can they trust the vendor, or were those parts from offshore? Etc, etc....
Sometimes I wonder if sensitive government installations are paranoid enough. Probably only the wrong ones are.
Re: (Score:2)
Who knows what is happening to the BIOS with modern motherboards and Windows.
Re:I thought this was invalid anyway (Score:5, Informative)
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.
Parent
Re: (Score:2)
This would work great, if your system was running *no software*. Unfortunately, the scheduler's job is to run software as quickly as possible - not give you consistent timing numbers. When it comes to actual computers running actual applications, a 1% timing change is well within normal variance.
As for being
Re:I thought this was invalid anyway (Score:4, Informative)
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
Parent
Re: (Score:3, Insightful)
Re: (Score:2)
-nB
Re: (Score:2)
http://www.bootdisk.com/ [bootdisk.com]. They either have it, or they will have a link for it.
Re: (Score:2)
http://www.nu2.nu/pebuilder/ [nu2.nu]
DRM (Score:3, Insightful)
Yay, DRM in every piece of hardware to the rescue!
Re:DRM (Score:4, Insightful)
Sounds actually like the exact opposite. DRM tries to hide away things, while this would give devices the ability to see everything that goes on inside the system RAM.
Parent
Re: (Score:2)
Digital signatures on all OS and software components, in-system messages (down to OS call level) and anything else that happens in the system is actually a very good way to defeat many possible attacks. Unfortunately without hardware acceleration on RSA and friends this is likely to bring even the fastest modern computer to a crawl.
Quite the opposite (Score:3, Insightful)
DRM is exactly the opposite. Locking away your computer's inner workings from you, taking away your chance to see what's going on inside.
BIOS (Score:2, Insightful)
Re: (Score:2)
Perhaps it might exploit a security hole [slashdot.org] in the hypervisor itself.
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: (Score:2)
If the player can read it, I can read it.
Re:AACS "Improvement" (Score:4, Informative)
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.
Parent
Re: (Score:2)
Re: (Score:2, Insightful)
Not "anyone" (Score:2)
What she demo'ed was a way to prevent a card on the PCI bus from having the same view of RAM as the CPU does. Unless the players have an architecture like a PC motherboard her attack may not apply. Fundamentally her attack works because there are two channels for getting information from RAM and the two can be configured differently.
Trying to have her cake and eat it too? (Score:5, Insightful)
And now a year later, she claims we need specialized hardware interfaces to scan memory for rootkits, even though this problem is laughably easy in the world of virtual machines.
And on to the actual work [com.com] ... the research basically observes that MTTR registers (some of the MSRs in the CPU) can cause memory mappings to look different between the CPU and the northbridge, and then comes up with a pretty easy way to cause the northbridge to either lock up or read data that is different (really easy once you see the specs for the appropriate registers). And she totally ignores the possibility of a system defending itself against this attack by verifying the registers she's modifying. Lousy research, girl.
Oddly enough, this "hack" is ALREADY IN USE ON YOUR SYSTEM and is actually necessary. See, when the processor is running in SMM (System Management Mode), it switches to exactly this configuration: the PCI bus sees VGA hardware mapped at the well-known address, but the processor maps the RAM at that address, which gives SMM mode a few kilobytes of memory that the normal system can't touch. SMM mode is used for things like "legacy USB devices" (e.g. having your USB keyboard act like PS/2 so DOS can use it) and other implement-in-software hacks that your OS doesn't know about, but your BIOS vendor gives you as "value-added features".
Re: (Score:3, Interesting)
Gee, I read the articles on the other end of those links and they boil down to two points - (1) it is hard to do and (2) it is detectable via timing analysis
Obviously (1) is really no defense at all because it only needs to be do
Re: (Score:2)
Can you point out a reason why it would NOT work today? And what mechanisms are in place today to ensure that this trickery does not occur?
Either rebut the core argument, that hardware-based memory retrieval is subject to manipulation by malware, or join a discourse. But to dismiss out of hand has no merit. Whether the mechanisms for remapping I/O space are legitim
Re: (Score:2)
The case under study is a rootkit preventing external analysis. The real system has lost its ability to defend itself by that point, or else it wouldn't be rooted. The real system is no longer in charge of the memory mapping registers after the rootkit takes over. A system trying to defend itself against an attacking process that has direct hardware access is a system
Re: (Score:2)
She's a girl (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
good luck... (Score:3, Insightful)
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: (Score:2)
W
Re: (Score:2)
But it's far more likely that someone will just offer more detailed services for a higher price. Or you can rent one probably for about $1,500 per month.
The other alternative, building one's own, requires getting under NDA with Intel. But even that's no guarantee.
FireWire access can also be redirected (Score:2)
The slide set mentions accessing memory via FireWire, but doesn't say much about it. FireWire understands packets for "reading and writing memory", along with ordinary data packets. But whether memory access packets actually read and write physical memory is up to the driver, when it configures the FireWire controller. The driver can set controller registers so that the physical address range accessible from the hardware controller is limited. Other addresses just pass the packets to the driver.
So i
Re: (Score:2)
Macs a few years ago didn't restrict Firewire access, and there was a demo of vandalizing the video display by plugging in an iPod.
Ref. Dornseif, CanSecWest 2005. His results about writing were
OS X: works
FreeBSD: works
Linux: works
Windows 2000: crashes
Windows XP: doesn't work
Except that Adam Boileau demonstrated write access to RAM under Windows from Firewire by having the device lie abo [security-assessment.com]
It's broken in Linux, too. Clear security hole. (Score:3, Informative)
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,
Seems like some useful service being provided... (Score:2)
Your Philosophies (Score:2)
If you check the comments below, (to a very good article) some commenters are rather hysterical, (in a bad way) and for good reason, but reflect the truth.
Rootkits headed for BIOS
Comments:
http://www.securityfocus.com/cgi-bin/index.cgi?c=a rticlecomments&op=display_comments&ArticleID=11372 &expand_all=true&m [securityfocus.com]
Re: (Score:2)
"There are more things in heaven and earth , Haratio, than are dreamt of in your philosophies."
Re: (Score:3, Insightful)
It's true that there are more males than females in in CompSci, but the ones which are there are no more and no less attractive than the average girl in any other line of work. Same goes for the males.
What the people in CompSci do share is an above-average passion for computing, abstract thinking and maths. (or if they don't they don't belong in CompSci regardless of sex) but neither of these things have any influence on looks.
Re: (Score:2)
Yeah. Because the only valid reason for anyone to have anything to do with CompSci is because they love the art of it. Anyone pursuing CompSci for any other reason should be kicked out and scoffed. Let's forget the fact that maybe they see CompSci as a way to make the world better.
Lame.
Re: (Score:2)
The human mind has limits. I am not convinced that it is *possible* to keep learning and studying abstract topics at an advanced level for literally decades without passion. Sure, you can go trough the moves, let your eyes scan the pages, but can you force yourself to pay full attention, to think about a particularily hard problems sometimes at 3am in the nigth when by chance y
Re: (Score:2)
Re: (Score:2)
By the way, simulation of automobile traffic patterns is a perfectly legitimate CompSci topic. (though the compsci major may (or may not) choose to express the same problem in different terms.
Re: (Score:2, Funny)
Plus when you think about it, sperm is the ultimate malware.
xkcd reference? (Score:2)
http://www.xkcd.com/c174.html [xkcd.com]
Re: (Score:2)
On the positive side, it wouldn't take much. Tandem-style computers, where two independent systems share the same motherboard and each CPU can access the memory/PCI bus/etc of the other in an asymetric fashion aren't new. The idea that one of the CPUs is the system master and always has precedence wouldn't be a big change. Such systems are quite expensive simply bacuase