分类：
2009-04-27 05:31:50
Note: The following post is a guest blog submitted to Microsoft Subnet by a security expert who wished to remain anonymous. Joanna Rutkowska recently released her new security whitepaper and exploit code entitled Attacking SMM Memory via Intel CPU Cache Poisoning. The thing that struck me about her research is just how easy this is to do. There is nothing super fancy or complex about the exploit code. Due to its simplicity, the odds are very high that this attack vector has been in use, even before this research published last month. Still, because this attack is so stealthy, we wouldn’t necessarily have been able to detect it.
Here's how the attack works in layman’s terms. First off, we need to set the stage a bit. The exploit code was only written for . The DQ35 is one of their modern boards. According to Joanna’s paper, Intel reported that their newest motherboards (DQ45’s for example) are not vulnerable to this attack. An exact list of affected motherboards was not offered in the research, nor any mention if AMD systems are affected as well.
The goal of the attack is to gain access to the normally very well protected SMM (system management mode) space. From there you would be able to load your SMM rootkit into SMM space giving you full control over the hypervisor or operation system. Another benefit is that your rootkit would be almost undetectable by the operating system. According to the whitepaper: "The memory controller offers dedicated locks to limit access to only to system firmware (BIOS)."
The exploit uses a form of Intel cache poisoning to get access to the SMM space that is supposed to be only accessible from system BIOS. Caching is used to increase performance of your computer. The CPU will use cached data first if it exists. So if you can replace the cache data with your own malicious data then you can be assured that it will be used in favor of the real data.
I should note that this particular exploit requires that the attacker already have admin or root privileges on the box. So this is not an attack that would be used to gain root access but rather a new way to hide your rootkit, key logger, or whatever code from detection on boxes you already "own". (We’ll have to wait and see if someone figures out a way to do a privilege escalation using this technique.) With the stage set here is a high level view of the three steps used by the exploit.
Notice the simplicity of this exploit.
1) Attacker modifies system MTR registers to change the SMM memory space from uncacheable to cacheable with type Write-back. The MTRR (Memory Type Range Registers), according to Wikipedia, are registers that provide the system software with control of how accesses to memory ranges by the CPU are cached. It uses a set of programmable model-specific registers (MSRs), which are special registers, provided by most modern CPUs. Any type Write-back writes to the CPU’s cache are marked dirty. This will force their contents to be written to memory later.
2) The attacker now can write code into the memory space that is normally reserved only for SMM functions. The attackers accesses to this memory space are now written to the CPU cache because of the changes made in step one. Normally SMM space is marked uncacheable and the chipset will discard any attempts at access except from system BIOS.
3) Now the attacker code is in the CPU cache memory normally reserved only for SMM. To execute the code the attacker issues an SMI. This triggers a CPU preempt that transfers execution control over to SMM code. The CPU will execute the SMM code but it will fetch it from the cache before DRAM. The attackers data is in cache (step 2) so it is executed. The code now runs with full SMM privileges. Remember that SMM is the most privileged on the box, more so than the operating system or any hypervisors.
The proof of concept exploit includes the code for doing this on a Linux operating system with an Intel DQ35 motherboard with 2GB of memory. It turns out that Linux allows the root user to access MTR registers incredibly easily. With Windows it can still be done but requires much more work and skill. No Windows exploit code was released.
This attack is hardware specific so if you don’t have the exact setup the exploit runs on it will not work. You would have to first figure out the SMM memory space location on your system.
The whitepaper offers this as a workaround:
"Intel has informed us that they have been working on a solution to prevent caching attacks on SMM memory for quite a while and have also engaged with OEMs/BIOS vendors to implement certain new mechanisms that are supposed to prevent the attack. According to Intel, many new systems are protected against the attack. We have found out, however, that some of Intel’s recent motherboards, like the popular DQ35, are still vulnerable to the attack. Additionally, the workarounds that Intel has mentioned to us are not yet officially documented, but Intel told us that they will be updating the CPU documentation shortly."
You can check Intel’s security advisory page here http://security-center.intel.com/default.aspx for any updates as well. To read the full whitepaper and download the exploit’s proof of concept code go here: http://theinvisiblethings.blogspot.com/
Now that the attack has been released what are your thoughts on it? Do you think it has merit?
If you have a guest blog that you would like to see appear on Microsoft Subnet, contact editor Julie Bort by e-mail or .
Visit the Microsoft Subnet web site for more news, blogs, podcasts. Subscribe to all Microsoft Subnet bloggers. Sign up for the . (Click on News/Microsoft News Alert.)
Follow
Linux is nice because it exposes much about your system that Windows hid from the user. That's not to say that getting at the MTRRs on Windows is going to slow down any attacker who has already got root ownership on the machine... Oh - that's probably 90% of all Windows Users who log in as Administrator. MTRR are typically manipulated by graphics drivers - subverting a graphics driver is one possible approach. There are probably others.
... except that if you have root priviledges on Linux, the only thing this exploit gives you is another way of hiding your tracks. If the system has been logging to another server, your tracks aren't coverable. Now if you can exploit the BIOS so much that re-imaging of the system doesn't remove your presence, you might be in business. But I doubt that is possible.