The quest for ring zero

'One ring to rule them all...'

Build a business case: developing custom apps

Federico Biancuzzi sits down with French researcher Loïc Duflot and speaks about the System Management Mode attack, how to mitigate it, what hardware is vulnerable, and why we should be concerned with recent X Server bugs.

A feature called System Management Mode, included in modern x86 cpus, opens the way to the land of kernel space and the quest for ring zero.

Could you introduce yourself?

I am a security engineer and researcher for the scientific division of the French National Security Agency, namely the Central Directorate for Information Systems Security in Paris. I am also a second year Phd student in Paris XI University. My research work is mostly focused on the security aspects of interactions between hardware components and software.

What is SMM?

SMM stands for System Management Mode. System Management Mode is one of the four modes of operation of most x86 processors (Intel Xeon, Intel Pentium, or AMD Athlon, for instance). Modern operating systems (such as Linux, BSD, or Windows) run in so-called protected mode. In protected mode, four different processor privilege levels (also called rings) are available, ring zero being the most privileged one and ring three the least privileged. Kernels of operating systems run in ring zero, whereas userspace code runs in ring three. The set of operations available to ring three code is restricted by hardware-enforced security mechanisms such as segmentation, paging, and I/O privilege restrictions. A few security-critical assembly language instructions are also restricted to ring zero operation. Most software security techniques (PaX on Linux, W^X on OpenBSD, and so on) heavily rely upon protected mode enforced mechanisms. On the contrary, System Management Mode is a 16-bit mode of operation dedicated to system maintenance. Code running in System Management Mode is running with full privileges on the system (free access to physical memory and to peripheral devices). Protected mode security mechanisms (paging, segmentation, rings, ...) are not enforced while in System Management Mode.

How did you have the intuition to take advantage of this feature?

The PhD thesis I started one and a half years ago deals with the security issues related to interactions between hardware components and software. I chose to read x86 processor-related documentation to get a better picture of what x86 processors were capable of. I read about the SMM functionality and I shortly noticed that it could be a threat to the global security policy of a system. I chose to look a little closer on the matter.

Is SMM used to do good things as well?

As a matter of fact, SMM is routinely used. Operating systems run in protected mode. But operating systems are not meant to be able to handle very specific hardware events (real time clock-related issues, thermal sensor signals or other external events, the list is really endless). In case such an event occurs, the chipset of the system generates a physical interrupt on the motherboard called an SMI (System Management Interrupt). Upon reception of the SMI, the processor will store its entire context and switch to SMM to run the code - which I'll call the SMI handler from now on.

By context, I mean most processor registers including control registers, task registers, instruction and stack pointers. It runs the code that has been written by the BIOS or motherboard manufacturer to handle the SMI, that is to handle the hardware-specific event that caused the SMI to be generated in the first place. When the handler runs the assembly language instruction "RSM", the processor will restore its entire context and switch back to protected mode.

So, as far as the operating system is concerned, nothing happened. The operating system did not notice the CPU switching to SMM and back to protected mode. Code execution in SMM is transparent from the operating system point of view.

During normal operation of a PC, SMIs are routinely generated, but neither the operating system nor the end user are aware they exist and that the CPU is handling them. I think it is pretty obvious that if such a mode can be misused, consequences on system security can be disastrous. As a matter of fact, the security of SMM comes from the fact that the SMI handler is loaded in memory at boot time by the POST sequence of the BIOS in a memory block called SMRAM located in main system memory.

On systems that are not equipped with a chipset that provides an 8-bit configuration register called the "SMRAM control register" (accessible via PIO accesses), protection of the SMRAM in protected-mode is only enforced by segmentation and paging.

On systems equipped with such a chipset however, the security model is essentially that only code running in SMM should be able to modify the content of the SMRAM. In other words, only the SMI handler should be able to modify itself.

What is the link between SMM and SMRAM control registers?

I said the security model was that only the SMI handler was able to modify itself. That is only a simplified picture. What the "SMRAM control register" does is first it enables the relocation of the SMRAM base address at physical address 0xA0000. This way, the SMRAM address range is in conflict with the legacy video RAM range. So what happens is that if the CPU is running in protected mode, all accesses to the SMRAM range are forwarded by the chipset to the display adapter. And if the CPU is running in SMM, the accesses are redirected by the chipset to the SMRAM in main system memory.

So far, the model seems consistent. The trouble is that there also is a bit called D_OPEN in the chipset. If this bit is set, the chipset forwards all accesses to the SMRAM range to the actual SMRAM. If this bit is set, SMRAM can be accessed whichever the mode of operation of the processor is. It should also be noted that there is in the SMRAM control register a bit called D_LCK. If this bit is set, the SMRAM control becomes read only, and only a hard reset can clear the D_LCK bit. If this bit was set after the D_OPEN bit has been cleared, then it would be impossible to modify the default trusted SMI handler while in protected mode. The trouble is that on all the desktops I tested the D_LCK bit was cleared.

Endpoint data privacy in the cloud is easier than you think

More from The Register

next story
14 antivirus apps found to have security problems
Vendors just don't care, says researcher, after finding basic boo-boos in security software
'Things' on the Internet-of-things have 25 vulnerabilities apiece
Leaking sprinklers, overheated thermostats and picked locks all online
iWallet: No BONKING PLEASE, we're Apple
BLE-ding iPhones, not NFC bonkers, will drive trend - marketeers
Multipath TCP speeds up the internet so much that security breaks
Black Hat research says proposed protocol will bork network probes, flummox firewalls
Only '3% of web servers in top corps' fully fixed after Heartbleed snafu
Just slapping a patched OpenSSL on a machine ain't going to cut it, we're told
Microsoft's Euro cloud darkens: US FEDS can dig into foreign servers
They're not emails, they're business records, says court
How long is too long to wait for a security fix?
Synology finally patches OpenSSL bugs in Trevor's NAS
Israel's Iron Dome missile tech stolen by Chinese hackers
Corporate raiders Comment Crew fingered for attacks
prev story


7 Elements of Radically Simple OS Migration
Avoid the typical headaches of OS migration during your next project by learning about 7 elements of radically simple OS migration.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Solving today's distributed Big Data backup challenges
Enable IT efficiency and allow a firm to access and reuse corporate information for competitive advantage, ultimately changing business outcomes.
A new approach to endpoint data protection
What is the best way to ensure comprehensive visibility, management, and control of information on both company-owned and employee-owned devices?