Intel x86 architecture exploit: an analysis
Could old hardware be weakening your security posture? New research regarding a design flaw in pre-Sandy Bridge Intel processor architecture provides plenty of food for secure thought.
In his paper ‘The Memory Sinkhole’ Christopher Domas, a lecturer on computer science and engineering at Ohio State University, reveals an up to now hidden danger that using older technology can present. It has traditionally been the view that the age of the hardware is not an inherent security risk, but rather it’s the old software that runs upon it we should worry about. For example, an old machine running a Linux distribution is seen as being low risk whereas if you were to install an end of life Microsoft OS, such as Windows XP, on the same hardware platform then the risk factor rises exponentially. Domas rather turns that assumption upside down with his research into the now past its sell by date Intel x86 architecture.
You only have to read the abstract of the research paper to understand the problem: “40 years of x86 evolution have left a labyrinth of forgotten backdoors into the ultra-privileged modes. Lost in this Byzantine maze of decades-old architecture improvements and patches, there lies a design flaw that’s gone unnoticed for 20 years.”
That design flaw is what Domas refers to as the memory sinkhole, and he’s produced a proof of concept that ultimately hands control of the computer over to the attacker. What’s more, his firmware-level attack concept is such that your antivirus protection will not be able to detect or remove the malicious code, nor will reformatting the hard drive or even reinstalling a new OS. So what, exactly, is involved here and what are the real world implications?
Let’s refer back to that abstract to start with, and then we’ll move on from there. Domas writes that “In x86, beyond ring 0 lie the more privileged realms of execution, where code is invisible to AV, we have unfettered access to hardware, and can trivially pre-empt and modify the OS. The architecture has heaped layers upon layers of protections on these ‘negative’ rings… Exploiting the vast, unexplored wasteland of forgotten x86 features, we demonstrate how to jump malicious code from ring 0 into the deepest, darkest realms of the processor. The attack is performed with an architectural 0-day built into the silicon itself, and directed against a uniquely vulnerable string of code widely deployed on modern systems.”
What this means is that the vulnerability can exploit the most privileged areas of execution within the x86 processor architecture by, in effect, a brute force attack on the System Management Mode (SMM).
The original x86 architecture was such that it had three levels, or rings, of privilege with ring 0 being the highest realm of execution as it were. Over time further ‘rings’ were added to provide even deeper levels of privilege through separate mechanism so as to restrict ring 0 code from more powerful modes of execution.
So you have ring -1 or hypervisor, and ring-2 the SMM. Ring -2 has the ability to pre-empt ring -1 which gives it unrestricted access to platform hardware, it is the one ring to rule them all in other words.
So what happens in the memory sinkhole exploit scenario is that a technique to ‘remap’ the Local Advanced Programmable Interrupt Controller (APIC) across the SMRAM range during states of execution is employed. This remapping enables the APIC to accept memory accesses destined for the Memory Controller Hub (MCH) in advance, and provides any malicious ‘ring 0’ code with hands on the otherwise heavily protected SMM.
It’s this level of penetration that gives the vulnerability persistence, be that surviving hardware changes such as a new hard drive or software ones such as an operating system reinstall. In the proof of concept, Domas releases a secondary payload that is installed by ring 0 and runs with SMM privileges, after the SMM handler is hijacked through the sinkhole. This secondary payload is able to do many things, including the installation of deeply persistent rootkits, the disabling of cryptographic checks and ultimately even system destruction by disabling its ability to run.
All of which is pretty serious stuff, although it should be tempered against a number of real world factors. First of which is that we are talking older tech here, not the Intel architectures most of us are using today. Intel has fixed the problem in everything from Sandy Bridge onwards, and is currently on a backwards fixing schedule for good measure. An Intel spokesperson has said that it is “releasing mitigations” for the privilege escalation issue, including updates for those server motherboards that support Westmere architecture.
It is likely that Intel will continue to patch for Nehalem as well, and board vendors are also on board (if you will pardon the pun) to deliver patches. This is not a silver bullet though, as the very fact that we are talking older hardware here, hardware that is no longer supported in many cases, would suggest that, well, no support will be offered to the owners of large swathes of susceptible machines.
However, even if you are using pre Sandy Bridge hardware, there’s no reason to run for the hills. This is not an easy exploit to pull off; in fact it’s one of the more complex that I have come across in recent years. For a start there’s the relatively simple to grasp matter of having to inject code onto your machine in the first place. This requires admin/root permissions and would need to get past any installed AV software for good measure, so that already throws a real world spanner into the probability of infection works.
Of course, many people do still get infected with all sorts of malware despite these hurdles needing to be jumped, so the second barrier to success is the complexity of the attack itself. Domas admits as much in his paper when he writes: “The APIC register window is fixed to a 4KB range, and required to be aligned on a 4KB boundary. The processor has some limited control over the APIC registers, but the vast majority of the 4KB register window is hardwired to 0. In practice, this offers ring 0 code the ability to “sinkhole” a single page of SMRAM by relocating the APIC – memory reads from the region return 0, and memory writes are discarded. The course granularity of the APIC position, combined with the inability to effectively control the APIC data, make the vulnerability extremely difficult, but not impossible, to apply in practice.”