Feeds

The quest for ring zero

'One ring to rule them all...'

  • alert
  • submit to reddit

Using blade systems to cut costs and sharpen efficiencies

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.

The smart choice: opportunity from uncertainty

More from The Register

next story
NEW, SINISTER web tracking tech fingerprints your computer by making it draw
Have you been on YouPorn lately, perhaps? White House website?
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
LibreSSL RNG bug fix: What's all the forking fuss about, ask devs
Blow to bit-spitter 'tis but a flesh wound, claim team
Black Hat anti-Tor talk smashed by lawyers' wrecking ball
Unmasking hidden users is too hot for Carnegie-Mellon
Manic malware Mayhem spreads through Linux, FreeBSD web servers
And how Google could cripple infection rate in a second
Don't look, Snowden: Security biz chases Tails with zero-day flaws alert
Exodus vows not to sell secrets of whistleblower's favorite OS
Own a Cisco modem or wireless gateway? It might be owned by someone else, too
Remote code exec in HTTP server hands kit to bad guys
prev story

Whitepapers

Seven Steps to Software Security
Seven practical steps you can begin to take today to secure your applications and prevent the damages a successful cyber-attack can cause.
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.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.