Exclusive Interview: Going Three Levels Beyond Kernel Rootkits

Breaking Past Hardware-Based Protection

Alan: With "red pill," you showed how it also possible to detect when an application was running within "The Matrix." In your proof-of-concept, you simply looked at IDTR via the SIDT instruction.

Joanna: Not inside the Matrix, but inside a Matrix. There’s a difference between detecting a virtualization versus a specific hypervisor, such as BluePill, as I said earlier. Also, note again that RedPill was targeting detection of software-based virtualization, as was used by VMWare products before Intel and AMD introduced VT-x/AMD-v (pre-2006). My original RedPill that was published in 2004 was unable to detect hardware virtualization.

Other people presented detectors capable (or sometimes not) of detecting hardware virtualization--this was in 2006 and 2007, after my original presentation at Black Hat (in the summer of 2006) about BluePill.

Alan: So, four and a half years later, we now have identification of virtual machines via other shifted tables, such as the global descriptor table and local descriptor table, but still adhering to the same concept.

Joanna: This is because, while pretty much all the machines we can buy today have VT-x support, some virtualization products still use software-based virtualization. I think VMWare Workstation still uses it when running 32-bit guests. The new virtualization detectors--next generation "RedPills" if you prefer--those capable of detecting VT-x/AMD-v virtualization, are usually timing-based, or caching-based.

Alan: If you're a good guy, you're worried about malware that runs in Ring-1. Identifying the presence of a virtual machine is therefore helpful. If you're not supposed to be running in a VM, but somehow you are, red flags can be raised.

Joanna: Sure, but let's not forget that the world seems to be moving towards virtualization, even used on desktop systems--Xen Client Initiative (also known as Project Independence), or Phoenix HyperCore.

Alan: With that said, if you were the evil guy running the virtual machine, couldn't you spoof the results to make the stealth malware remain hidden? That is, if it saw an application requesting the IDT and the next line of code is "does the result start with 0xc0 or 0x80," it would just spoof the results? So how do we protect against that type of attack?

Joanna: You don't, but such attacks assume that the evil guy knows the actual binary of the detector in advance. In other words, the evil guy must have a database of all the potential detector binaries, and which bytes inside those binaries should be "hooked" (such as the SIDT instruction) so that the binary executed as if there was no virtualization. Those are "implementation-specific attacks." They don't scale well, but are, of course, used in the wild by malware (not necessarily to cheat about virtualization being enabled or not, but rather to simply disable popular A/V programs).

Looking from the good guy's perspective, you cannot prevent such attacks if you execute at the privilege less than or equal to that used by your opponent. That is one reason why A/V products are losing the battle with kernel-mode rootkits, which often can disarm a known A/V kernel mode agent because, well, it is well-known and they can prepare an implementation-specific attack against it. Then the new version of the A/V tool comes out, and all the malware needs to be updated and so on. The arms race continues, the bad guys makes money and enjoy life, A/V also makes money and enjoy life, albeit without meeting its declared goal, which is to protect the user.

Alan: And the arms dealers make money on both sides of the war. Some current stealth malware is designed to shut off its most malicious actions if it's being run in a VM. The bad guys are doing this so that security researchers will have more difficulty identifying the true capabilities and dangers of the malware. So, if the malware is looking for IDT starting in high memory, why not have home users run operating systems that put the IDT in high memory? The home user is least-likely to run a VM, and the malware writer will not know if seeing the IDT in high memory means that they've infected a clueless home user (which is awesome) or if they're being run within a VM by a skilled researcher who’s set up a trap?

Joanna: Malware authors would quickly realize that it’s not worth it to avoid "virtualized" systems anymore, and we would get back to the same point where we are today.

Alan: But you’re one step ahead now because you’ve moved the clock forward, because the malware cannot hide behind obscurity by cloaking within a VM. So if it took x days for the security researcher to develop the countermeasure against the malware’s neutered VM mode, and then y days to analyze the sample and develop the countermeasure, you’ve just decreased “time in the wild” by x days?

Joanna: As I said earlier, this is naïve thinking and does not offer any protection in the longer term.

Alan: Ok. Your team didn't stop at Ring -1. What's happening at Ring -2?

Joanna: Yeah, Ring -1 malware is so 2006! Every x86 CPU has also something that is called System Management Mode (SMM), which itself is nothing new, as it has been present since the 80386 processors. What makes it interesting now is that when virtualization has been added to the processors, it turned out that SMM mode actually was granted higher privileges than the newly introduced Ring -1 hypervisor mode. Thus we called it "Ring -2" to stress its power over the hypervisor mode.

Our team hasn't been the first that played with SMM, however. In 2006, Loic Duflot presented a very nice attack against OpenBSD securelevel mechanism that used SMM mode. Loic used SMM as a "tool" in his attack, not as a target. Back then, in 2006, it was not unusual for the SMM not to be protected in any way on most systems--so if one had root access (or kernel-mode access), one could inject any code they wanted into the SMM and had it executed with SMM privileges. Of course, one still had to have this root or kernel access to do that.

But then system vendors started securing the SMM mode. The special part of DRAM that is used to hold code executed in SMM, which is called SMRAM, got special protections imposed by the chipset (Memory Controller Hub, to be precise). On most of the current systems, it is thus highly non-trivial to get any code executed with SMM privileges. One needs to find a bug in the chipset or BIOS in order to do that (even if we have kernel-mode access). In fact, at the last year's Black Hat in Las Vegas, Sherri Sparks and Shawn Embleton presented about SMM rootkits, and they made it clear that their rootkits could only be loaded on older systems (pre-2006). Interestingly the very next day, we had a series of presentations about Xen compromises, and we discussed a bug in Intel BIOSes that allowed for arbitrary code execution in SMM mode. I believe this was the first publicly discussed bug to allow to bypass SMM protection. Since that time, we have found two other ways to get into SMM mode on various systems. One another attack we found at the end of 2008 affected a large number of Intel-based systems (and potentially also with other BIOSes too) and we used it to bypass Intel TXT during our presentation at Black Hat DC in February.

This bug is still being patched by Intel and we are planning to present the details at the Black Hat USA next month. Yet another bug we found earlier this year was in the caching semantics as used by Intel CPUs. This very same bug has also been discovered independently by Loic Duflot and we agreed with Loic to publish a paper on this bug on the same day as Loic was presenting on this at a conference.

So, to sum it up, SMM rootkits (or Ring -2 rootkits) require access to the very well-protected SMM memory, and on most systems today an attacker must use some sort of an (often non-trivial) exploit to get there.

Alan: Are these SMM attacks limited to specific hardware?

Joanna: They are usually limited to given BIOS version (or atleast a family of BIOS products) and also to specific family ofchipsets like 3- or 4-series Intel chipsets.

  • johnbilicki
    I presume 4GB is limiting on a casual-use laptop because Joanna also runs virtual operating systems on her general purpose laptop?

    How did you two end up talking about Macs instead of something like rootkits or other things more relative to Joanna's line of work?

    As a web developer security is very important though I find it's fairly easy in most regards as attacks, bots, spammers, etc overwhelmingly (though not always) use the same approach methods so there are plenty of patterns that differentiate from normal web traffic. Easy isn't where the fun is though. I'm curious as to the parallels with software in general?
  • truehighroller
    I think she has very nice fat looking lips. xD
  • johnbilicki
    truehighrollerI think she has very nice fat looking lips. xD
    ...not to pick a fight truehighroller...but I don't think most women would find such a statement very "welcoming". Nerd girls rock a hundred times more then girls with only cliche interests, but comments such as yours aren't only unwelcome or alienating by most women they annoy those like myself who highly appreciate women with more refined qualities. Show some dignity and respect and stay on topic or please go else where.
  • Interesting interview, and kudos for treating her as a "security expert" and not as a "female security expert".

    In the majority of interviews with young female professionals the interviewer "just have to mention" their hair colour, clothes or makeup. Nice to see a break from that rather tiresome practice
  • Humans think
    I also use Macs myself (also windows systems and linux ones), but I had to say it: Alan Dang you sure are an Apple fanboy :P
    This woman knows what she is talking about, I think I am in love :)
  • thx for spending the time to discuss this complex world in easy to understand terminology. good luck with the R-3 presentations!
  • haplo602
    read the interview because I was curios about the girl on the picture. turned out to not even be interesting.

    f.e. the bluepill thing. ok you can jail the OS into a VM transparently. Now what can you do ? you have to implement a mini OS by yorself into the hypervisor to do anything usefull (i.e. data collection), you need to read the FS, interrupt the network etc. the only usefull thing is to infect the system again after it was cleaned (again you need to know the FS). but since the AV knows you are there, it knows what to do about it.

    ok AV vendors are a step behind (or 2), but once they figure out the attack vector and means, you are done and have to come up with a new attack technology. there are only limited options available on each architecture that change with each revision, so the AV companies win in the end by closing all the gaps they know about.

    these are only backdoors to break the AV protection or work in a dimension higher than the AV protection. however the usefull data is still on the same level as the AV protection (user space).
  • candide08
    Being SUCH an obvious fanboy makes me suspect many other aspects of your judgment. Please TRY to stay objective.
  • coolkev99
    Interesting... and way over my head. Yet I couldn't help but feel like they were trying to out-geek each others commments.

    She is to nerds what nerds are to normal people. Don't get me wrong, much respect and admiration!
  • A interesting and informative article but there is a lot of self praise and back slapping, seems that these folks are not the geniuses they make them selves out to be: