Another day arrives and, with it, another way to run code. This time, it's executing arbitrary code in System Management Mode (SMM) memory. That sounds kind of exciting, right? A SMM rootkit? Does that mean that we need an anti-malware scanner for SMM memory now? Or will it just fade away? All this and more will be answered shortly. But first...
 
The technique was discovered last year by Loïc Duflot. Loïc has been researching and publishing work on SMM for several years already. The same technique was discovered this year by Joanna Rutkowska. Joanna is perhaps most famous for her Blue Pill work. 
 
The attack is based on a well-known technique - cache poisoning - but applied to a new context. Apparently, Loïc and then Joanna contacted Intel about the technique, but interestingly, Intel engineers knew about it already. In fact, they had even documented it in the data sheet for the 5100 MCH chipset: "The chipset/platform cannot protect against processors who attempt to illegally access SMM space that is modified in another processor's cache". This is exactly what is being exploited.
 
There are lots of caches in modern hardware, and several of them can be filled under user control with arbitrary data for execution. For example, the Translation Lookaside Buffer (TLB) is perhaps the most accessible cache. An attacker can fill a TLB page with code, mark the entry as global so that it won't be flushed by default, and then remove the corresponding page table entry. This was my "invisible code" technique. Or a defender can time filling a TLB page with data, execute an instruction that is known to cause a fault in a virtualised environment, and then time a second access to determine if a refill occurred. That was my technique to detect Blue Pill. ;-) There are other caches and other ways to play with them, but we'll come back to that.
 
Yes, SMM code execution has been discussed for years already. In fact, some of us discussed using it to detect Blue Pill-style attacks, since the SMM environment exists outside of any virtualised environment. More recently, a SMM PS/2 keyboard sniffer was described, but the author of that attack was relying on the chipset not locking access to the SMM memory. The advance that was presented at CanSecWest was to bypass the locking mechanism, without requiring physical access to the system.
 
The technique begins by marking a region of memory as Write-Back cacheable. This memory has to correspond exactly to a region occupied by SMRAM. The Write-Back property is required so that writes to memory are cached until flushed, because the SMRAM is not directly writable yet. To determine this address for writing requires a little bit of fiddling, since there is no readily-readable map. Once the correct memory region is marked as cached, the attacker writes the required code to that location, then triggers a System Management Interrupt (SMI). Since the written memory is cached and appears to belong to the SMRAM, the CPU will execute the contents of the cache instead of reading the SMRAM, in the context of the SMM. The code that executes from the cache could then write directly into the real SMRAM, if a multi-stage payload was required.
 
However, let's not get carried away with all of this. The address of the SMRAM is variable, so hard-coding something won't work, and the code in SMRAM cannot survive a reboot. That makes it very system-specific, and that rules out widespread exploitation. On Windows, administrator privileges are required to access the PhysicalMemory device, and it normally requires ring 0 code to read and write MSRs and MTRRs (ring 3 code, by default, cannot execute privileged instructions). Another privilege is required to load a driver to perform those actions. This all sounds very much like Blue Pill again. Even if you manage to get into SMRAM, what will you do next? You can't hide there, because paging is disabled, and SMIs cannot be disabled. It is trivial for another application to perform the read attack to see what's inside.

The next big thing? Needing an anti-malware scanner for SMM memory? That probably won't happen any time soon. Of course we're keeping an eye on it, and we'll do the right thing.
 
-- Peter Ferrie