Feeds

The quest for ring zero

'One ring to rule them all...'

  • alert
  • submit to reddit

SANS - Survey on application security programs

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.

High performance access to file storage

More from The Register

next story
Obama allows NSA to exploit 0-days: report
If the spooks say they need it, they get it
Putin tells Snowden: Russia conducts no US-style mass surveillance
Gov't is too broke for that, Russian prez says
Snowden-inspired crypto-email service Lavaboom launches
German service pays tribute to Lavabit
Mounties always get their man: Heartbleed 'hacker', 19, CUFFED
Canadian teen accused of raiding tax computers using OpenSSL bug
Heartbleed exploit, inoculation, both released
File under 'this is going to hurt you more than it hurts me'
Arts and crafts store Michaels says 3 million credit cards exposed in breach
Meanwhile, Target investigators prepare for long process in nabbing hackers
Canadian taxman says hundreds pierced by Heartbleed SSL skewer
900 social insurance numbers nicked, says revenue watchman
prev story

Whitepapers

SANS - Survey on application security programs
In this whitepaper learn about the state of application security programs and practices of 488 surveyed respondents, and discover how mature and effective these programs are.
Combat fraud and increase customer satisfaction
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Top three mobile application threats
Learn about three of the top mobile application security threats facing businesses today and recommendations on how to mitigate the risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.