nCircle.com >> 360 Security

« cansecwest/core06: "More on uninitialized local variables" | Main | SCADAGard SIG To Be Established »

cansecwest/core06: "security issues related to Pentium SMM"

Loic Duflot
Title: Security Issues Related to Pentium System Mgmt Mode

It is day 2 at Cansecwest and this talk wins for ‘so frightening that you want to hide under your desk in the fetal position’.

I’ll go through the high level technical and then end with pointing out a principal that is one of those universal truths I carry around with me everywhere.

This entire exploit is based on documented x86 functions.

Your CPU runs in a few modes, one of those modes is known as Protected mode, other known as System Mgmt Mode. When your OS is running, your in Protected mode and this is how much of the security is performed and you’ll hear of ring0 and ring3. Just know that your in-world universe is in protected mode.

System Management Mode (SMM) is used so that when there is something external to your OS world like say a thermal condition that needs to communicate some message, the CPU saves all its protected mode state out, does all this SMM stuff and then return to its regular scheduled program in protected mode.

There are details that evolve registry addresses and very low level operations but for the most part, a system in a very secure state can be circumvented via this SMM facility. I’m talking free access to all memory and IO.

The song goes a little like this:
Enable SMI
Open SMRAM space
Replace default SMI Handler by custom one (do your duty)
Close SMRAM space
Trigger SMI
Gain access to restricted operations.

In the wider picture: works on most systems. Turns out that Linux and the *BSD’s will fall victim to this attack strategy, however, Windows XP is not known to be exploitable because of a few system calls that are not present and more importantly a certain memory range in protected mode is not shared addresses to SMM.

So, for the demo, they did not pick some shabby OS to exploit. How about OpenBSD at level2 (high security) with allowaperture=1
Ummm…it worked. Theo, microphone please?

Theo spoke to this OPENBSD issue and said he and the team have known about it for a year. They are between a rock and a hard-place because Xserver is really the core of the problem. It has too much damn access to regesters and is in the most unfortunate address space in protected mode because when in SMM, what is in that address range can be used to exploit.
Solution is for Xserver people to abstract sufficiently so that the kernel can have more governance on the Xservers logic.

Closing TK comments:
A system or a world that has a policy governed by in-world mechanisms cannot be effective when a process in-world can reach to the out-world to cause in-world change. You could also say that since a problem cannot be resolved at the same logical realm it has been created, then it is also the case that the most effective governance of a world can only come from outside that world. Think about all the crazy things we do in the physical world. As soon as we could get to the strong and weak forces at the atomic level, we created a incredibly destructive device. I just hope that if string theory is right and there really are energy strings at the lowest level of the universe, that no one in our world get control of them. The negative outcome caused by the power hungry is too high a risk to even consider the positive benefits.

Its late and I have been blogging way too much today I am certain that my mental packet loss is abnormally high. I’ll return to this in-game out-game concepts later in another blog entry, when I am less sleep deprived.

--tk

Comments (1)

First of all, my appologies -- I've tried to get MT to properly break up my paragraphs, but it doesn't like <br> tags, nor is it auto-interpreting linebreaks, at least on the preview page. I'll use the ascii character for carriage return instead. :-) ↵

Here's my take away from that presentation (something security folks have lived by for a while but others may not be so aware of):↵

local access (whether physically local, or the ability to run code locally) == game over.↵

There are lots of really wonderful things people are doing to protect machines locally, and we have to keep trying them because we're forever running code that eventually allow local access (think IE, which is in many ways much harder to secure than IIS -- the flow of information on the web is server->client largely, so the client has the burden of the validation and verification to do), but at the same time, it's shown itself to be a losing battle. As complexity grows linearly, the challenge grows exponentially. Securing a machine with one or two remote services is maybe mostly possible. Securing a machine once someone has local access of any sort? You have to restrict the complexity of the system they have access to tremendously or you run into fun little quirks like this SMM hack.↵

It was great to chat yesterday during lunch, TK. Have a safe flight back.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About

This page contains a single entry from the blog posted on April 7, 2006 12:15 AM.

The previous post in this blog was cansecwest/core06: "More on uninitialized local variables".

The next post in this blog is SCADAGard SIG To Be Established.

Many more can be found on the main index page or by looking through the archives.