Pentium Computers Vulnerable to Attack?

An anonymous reader writes "One of the latest security scares is coming from security experts at CanSecWest/core '06 in the form of a possible hardware-specific attack. The attack is based on the built-in procedure that Pentium based chips use when they overheat. From the article: 'When the processor begins to overheat or encounters other conditions that could threaten the motherboard, the computer interrupts its normal operation, momentarily freezes and stores its activity, said Loïc Duflot, a computer security specialist for the French government's Secretary General for National Defense information technology laboratory. Cyberattackers can take over a computer by appropriating that safeguard to make the machine interrupt operations and enter System Management Mode, Duflot said. Attackers then enter the System Management RAM and replace the default emergency-response software with custom software that, when run, will give them full administrative privileges.'"

Comments

Sensational headline about a poor article.

[dfn_deux]

This hack assumes that the intruder already has write access to the nvram of the system. Also, the headline is just a cut/paste of a small portion of a poor article with few technical details. There is no PoC code, nor any specific chip mentioned. The headline refers to Pentium chips specifically and the articles says "any x86 based architecture, needless to say these are not interchangable terms... Shame on you Slashdot editors for posting this garbage...

A few more details

[Mr 44]

I can't find the actual paper anywhere, but this blog posting has way more details than the article originally linked ... Very interestingly, Windows XP is not vulnerable, but OpenBSD is.

Re:A few more details

[Cleveland Steamer]

Yes, this blog posting is interesting, but it still leaves some important details out.

Linux and *BSD have a /dev/mem device interface for accessing physical memory from user space. Usually, this device only allows access from a priviledged user:

crw-r----- 1 root root 1, 1 Dec 6 12:34 /dev/mem

Using /dev/mem, it should be possible to access the address range assigned to system management RAM. However, the CPU has a Model-Specific Register (MSR) for enabling and disabling accesses to SM RAM. The instructions that are used to read and write MSRs (RDMSR and WRMSR) must be executed from ring-0 (kernel level) or else a GPF occurs. However, the Linux kernel can be configured to provide a user level interface to MSRs via:

crw-rw---- 1 root root 202, 0 Feb 24 09:18 /dev/cpu/0/msr

Again, you'll probably need root priviledges to access the device.

Better article: no FUD-OpenBSD demo-Theo comment

[droopycom]

From : http://blog.ncircle.com/ (scroll down)

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