Intel left a fascinating security flaw in its chips for 16 years – here's how to exploit it

Turning this trick into something that can be exploited

So now we've seen how it works: force the powerful SMM code, the sysadmin of your PC, into reading from and writing to memory we more or less control. The next steps are easy, right? No. The local APIC's configuration registers are all over the place: there are huge gaps in its memory map where we can't control the contents. Reading from it returns a zero more than 99 per cent of the time.

Effectively, all we've got a 4KB page of zeroes that we can slap over the SMM code's private memory. Writing to it is pointless. Domas called it a memory sinkhole. The situation looked hopeless.

So Domas looked through Intel's sample SMM code, which is provided to firmware vendors to bake into motherboards. It turns out that pretty much all vendors use Intel's template SMM code.

This template code relies on a crucial data structure, the size and address of which is stored at 0x1FF8A000 in memory: a structure called the Global Descriptor Table (GDT). This table is a throwback from the 1980s. All operating systems need a GDT to do anything useful, because it tells the processor where data and executable code, among other things, are allowed in memory.

When the SMM code is entered from an SMI interrupt, it loads its GDT into the processor by giving it the size and address at 0x1FF8A000. By positioning the sinkhole over where the SMM code expects to read its GDT pointer, the processor will read zero. Before triggering the interrupt, you just make sure a table of our own devising is placed at address zero, and the CPU will load our GDT in SMM mode.

After that, we can redirect execution to somewhere more comfortable in memory while remaining in ring -2. Now we're running the show and not the hidden janitor. We can install our rootkit permanently in the firmware, so even if the hard drives are wiped and the apps and operating system reinstalled, it can be revived.

Exactly how this last part is done, we'll leave as an exercise for the reader. Domas has provided some sample code showing how to reprogram the APIC's physical address.

Fixes and mitigations

Again, this is fixed in Intel chips made from January 2011; you can't move the local APIC over the SMM's protected area. Virtual machines, whether they are in the cloud or on your desktop, cannot exploit this vulnerability (unless your virtual machine manager is braindead insecure and allows guest operating systems to remap real hardware). Techniques, such as monitoring the processor cycle counter, can be used to sniff out hidden rootkits: cycles stolen by the stealth malware will show up to application software.

You must have root or administrator-level access to a machine to exploit this chip bug; a malicious driver, or a program exploiting a privilege escalation flaw in an operating system, can abuse this Intel hardware vulnerability (assuming it's not running inside a virtual machine.)

So the sky is not falling in, but it is rather irritating, and people should be warned. As said earlier, what's truly at risk is old office PCs kicking around, or that loyal pre-Sandy Bridge Linux server you can't be bothered to decommission and replace.

Domas hasn't tried the attack on AMD processors. El Reg hopes the chip biz also spotted the design flaw. Intel has issued software fixes for its server motherboard families S5500HC and S5500HCT, and workstation board family S5520SC, to mitigate "a method that enables malicious code to gain access to System Management Mode (SMM)."

"There are hundreds of millions of computers out there that can't be fixed," Domas told the Black Hat conference. "Intel has been great about this, and published some firmware updates, but really, for some systems, this is unpatchable." ®

Additional reporting and technical info by Chris Williams. If you like this sort of in-depth coverage, drop us a note with ideas for more.