The recent SMM cache poisoning vulnerabilities released by the Invisible Things Lab team are a regular topic of conversation with customers lately. These vulnerabilities are definitely important, but they are not (currently) a huge practical threat, especially for non-virtualized system. They are an excellent reminder, though, that hardware – just like software – is not perfect and vulnerabilities are inevitable.
First, though, a little background on the vulnerabilities. System Management Mode, or SMM, is a privileged Intel CPU mode used for a variety of management functions, such as turning on fans when the processor gets hot or making a USB keyboard and mouse look like PS/2. SMM is a bit like the human brainstem: it’s an old part of the CPU that it ends up having enormous control because it’s responsible for handling all sorts of little low-level details. And just as the brainstem handles controlling our breathing or the pumping of our heart without involving the higher-level parts of our brains, SMM does its work in the background below the notice or control of any system software, such as an operating system (OS) or hypervisor. SMM offers unlimited access to all hardware and software on a system.
Not surprisingly, SMM is attractive to attackers because of all of this low-level access. Running a rootkit in SMM would make it both invisible to and in complete control of any system software or applications. An SMM rootkit could subvert even the most highly assured, formally verified OS. The hardware designers at Intel fully understood this power and the potential for attack, so they took steps to tightly control what software runs in SMM. That code – which is provided by motherboard or system vendors – is supposed to be loaded by the BIOS and then never modified. To prevent modification – the main mechanism used to prevent the introduction of rootkits – the SMM code is stored in special read-only memory.
Interestingly, the SMM vulnerabilities have nothing to do with breaking any of the read-only protections. Instead, the vulnerability is with the interaction with the CPU cache. Modern CPUs cache both code and data in very high-speed memory on the CPU itself in an effort to deal with the fact that CPU speed is increasing far more rapidly than memory. It turns out that it is possible to cache the SMM code in the CPU cache and the CPU will incorrectly run the cached copy on entry to SMM mode. Since the CPU cache is writable, this has the same effect as bypassing the read-only protections
This is a classic type of vulnerability. The designers were focused on protecting the access that they thought would be used for an attack and overlooked other avenues of access. The result is that a sufficiently privileged application (e.g., a root application on Linux) can change the code that runs in SMM to inject a rootkit or some other malicious application.
In the case of a traditional OS, such as Linux or Windows, this is an interesting but somewhat impractical vulnerability. These OSs correctly limit the access needed to manipulate the CPU cache to very privileged applications, so if you are to the point where you have enough access to launch the attack there are a million more straight-forward attacks that you can use.
The vulnerability is much more interesting in the context of virtualization using a hypervisor-based architecture. Typically, a hypervisor should be able to prevent the exploitation of one guest operating system from spreading to the entire system, including the other guests and the hypervisor. However, these SMM vulnerabilities, because of the hardware access that they leverage, allow the complete takeover of a virtualized environment from a single guest. For virtualization, this is a worst case vulnerability.
The impact on virtualized systems is what seems to have gotten peoples’ attention. Especially since these attacks offer a path to defeat the next-generation Intel technology aimed at, among other things, securing virtualized systems.
Again, I think that they are an excellent reminder that CPUs and other hardware are a source of vulnerabilities just like software. Many people – myself included – tend to focus on software vulnerabilities almost exclusively. Likely because there are so many software vulnerabilities and because the tools used by most developers so effectively hides the hardware details required to fully understand, discover, and leverage hardware-level vulnerabilities. These SMM vulnerabilities are a huge wakeup call reminding everyone that hardware vulnerabilities can exist and when they do they are likely to have devastating consequences.
In a way, it’s a testament to the engineering work of Intel and AMD that most software developers treat CPUs as infallible. Just like the floating-point math errors in early Pentium chips, these SMM vulnerabilities cause us to look at hardware with renewed skepticism. And once you start looking you realize that things are just as tough for hardware security as they are for software security. As more security features, such as TXT, are pushed down into hardware I expect that there will be more focus on finding vulnerabilities from the good and the bad guys. And I have no doubt that scrutiny will expose more flaws.
