Tom Olzak

Examining the SMM Hack and Pondering Intel’s Apathy

In Hacking on March 20, 2009 at 13:19

When security researchers notify us of new vulnerabilities, I am not seriously concerned about how long it’s been out there.  My understanding of reality extends to a reasonable timeline for vendor-driven remediation.  But when researchers are simply demonstrating yet another exploit against a months-old weakness, one the manufacturer has known about, then I lack understanding.  Rather, I am ‘very concerned’ (I try not to throw things across the room these days).

The vulnerability

Joanna Rutkowska (of Blue Pill fame) and Rafal Wojtczuk published a paper this week in which they describe a way to compromise a computer using Intel x86 processors.  When successful, the exploit results in malware residing on the target system which cannot be detected by the OS or anti-virus software—a rootkit.  The vulnerability used resides in System Management Mode (SMM) operations, running at a higher privilege level than the OS, implemented in x86 32 bit and 64 bit architectures.

Before jumping into how this works, let’s take a quick look at the SMM architecture.

What is SMM?

According to Intel,

SMM is a special-purpose operating mode provided for handling system-wide functions like power management, system hardware control, or proprietary OEM designed code. It is intended for use only by system firmware, not by applications software or general-purpose systems software. The main benefit of SMM is that it offers a distinct and easily isolated processor environment that operates transparently to the operating system or executive and software applications.

When SMM is invoked through a system management interrupt (SMI), the processor saves the current state of the processor (the processor’s context), then switches to a separate operating environment contained in system management RAM (SMRAM).  While in SMM, the processor executes SMI handler code to perform operations such as powering down unused disk drives or monitors, executing proprietary code, or placing the whole system in a suspended state. When the SMI handler has completed its operations, it executes a resume (RSM) instruction. This instruction causes the processor to reload the saved context of the processor, switch back to protected or real mode, and resume executing the interrupted application or operating-system program or task.

The following SMM mechanisms make it transparent to applications programs and operating systems:

  • The only way to enter SMM is by means of an SMI.
  • The processor executes SMM code in a separate address space (SMRAM) that can be made inaccessible from the other operating modes.
  • Upon entering SMM, the processor saves the context of the interrupted program or task.
  • All interrupts normally handled by the operating system are disabled upon entry into SMM.
  • The RSM instruction can be executed only in SMM.

Source:  Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3B, p. 26.1

What all this means is if an attacker manages to take control of SMRAM and manipulate SMM operation and processor execution, the target system will be compromised and the malware undetectable.  It also means this type of attack is not a likely candidate for mass malware distribution.  Let’s see why.

How SMM exploits work

To exploit weaknesses in SMM architecture, two things are necessary.  First, the hacker must have access to the controlling firmware and access for debugging.  Access to firmware and requisite reverse-engineering might be possible.  However, the nature of SMM architecture prevents easy debugging.  Remember, SMRAM is inaccessible by the OS and applications executing within it.  But once you’ve overcome this hurdle, you might try something like the following exploit, the one documented this week by Rutkowska and Wojtczuk.

  1. Mark the SMRAM as write-back cacheable by modifying appropriate registers.
  2. Write to physical addresses corresponding to locations where SMRAM is located.
  3. Trigger an SMI to transfer execution to the SMM code.

The attacker now has full control of the system, running code at the highest privilege level.  And while the code running within SMM may be undetectable, it has to get into SMRAM somehow.  This means activities leading to SMM compromise may be visible to the OS and to anti-malware software.

Why I’m concerned

This week’s exploit, and accompanying warnings, is just the latest in a series of findings starting at least as far back as 2006.  That was when researcher Loic Duflot demonstrated how an attack against SMM would work (Robert McMillan, 2008).  Duflot’s findings were confirmed during a Black Hat demonstration last year by Shawn Embleton and Sherri Sparks, and in a detailed PHRACK article published in March 2008.  And that’s not all.  According to Rutkowska and Wojtczuk,

… the very same cache poisoning problem we abuse in our attack against SMM has been identified a few years ago by Intel employees, who even decided to describe it in at least two different patent applications.

In other words, Intel employees allegedly patented mechanisms for correcting this design flaw.  I wonder why Intel didn’t use this information to remove the SMM vulnerability, why the company continued to knowingly expose customers to a rootkit threat.

Although some motherboards are free of the SMM weakness, many others are still vulnerable years after researchers raised the issue and after Intel employees came up with a solution.  So before you commit to a particular system to house national defense secrets or the organization’s crown jewels, check to see if you’re lucky enough to be getting a computer with secure SMM capabilities.

%d bloggers like this: