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.'"

What about MMUs

[Anonymous Coward]

someone could do the same with ANY interrupt handler... oh wait... an MMU would protect against that.

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...

Re:Aren't you already screwed?

[Ars Dilbert]

I suppose this could be used to elevate one's privileges. Restricted user runs the exploit code, and it spawns a process that runs under admin or system credentials.

A few more details

[Mr 44]

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

Re:FUD?

[c_forq]

If system heat becomes critical they will simply shut the system down flat out. On a Pentium 4, overheating is not entirely unexpected, particularly on the high edge of the clock speeds. On an AMD or Via, overheating is a major failure condition, probably caused by a heat sink falling off.

You are a little off. What a P4 does is "speed stepping" where if it is overheating it will down the clock and avoid areas on the chip that are the hottest, if it gets too hot it will shut down completely. This is designed so that permanent damage does not happen as a result of heat. AMD also has a similar feature now (or claims to, I've heard some cases of people having a heat sink failure and their AMD being trashed as a result), but they didn't used to (it used to be an AMD CPU would cook itself to permanent destruction if it was overheating, there is a good video of a few AMD chips lighting on fire at Tom's Hardware demonstrating this).

Re:Aren't you already screwed?

[mercut]

What a crock. At least the editors could have linked to the actual presentation [cansecwest.com] (beware, it's a ppt). I was at CanSec West and this is not as scary as you would think. The exploit requires escalated privileges to begin with. The only thing it can currently be used for is bypassing secure levels inside of OpenBSD, where you already have root. Next time the editors could do a little research before posting, oh wait, this is slashdot. --m

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.

Headbanger Virus

[jd]

The "Good Times" scare was a hoax, but it had an ancestor - the Headbanger virus - which actually could destroy the hard drive. It worked because neither DOS nor the drives had any kind of input validation. It was easy to derange the read heads - or break them entirely - by trying to go past the drive limits - first on one side of the drive, then on the other, repeatedly, as fast as the drive could operate.

It was also based a little in reality - CPUburn could theoretically destroy an improperly heat-sinked CPU by running massively heat-generating instructions in a tight loop that was entirely in L1 cache.

So, physical destruction could happen. It was extremely rare - most OS' are designed to place limits on program activity, and I know of only two Real World examples of such software that existed in the wild - but it was NOT unknown.

Re:FUD?

[Chris Burke]

You are a little off. What a P4 does is "speed stepping" where if it is overheating it will down the clock and avoid areas on the chip that are the hottest, if it gets too hot it will shut down completely. This is designed so that permanent damage does not happen as a result of heat. AMD also has a similar feature now (or claims to, I've heard some cases of people having a heat sink failure and their AMD being trashed as a result), but they didn't used to

AMD added this feature in the Athlon XP (maybe not the first release... perhaps Thoroughbred?), but it requires motherboard support and thus took a little longer before it became useful. I wish it'd been in earlier; I once forgot to take the sticker off the bottom of a heat sink, fried the processor in seconds. :P

P4's speed stepping doesn't actually change the clock speed, it just changes the duty cycle so the clock runs full speed for a while, then not at all for a while. Not what I expected at first, but really an elegent solution since it doesn't require designing a complicated PLL, but gives the same effect as cutting the frequency in half.

For the GP: When the P4 enters this mode it isn't really overheating per se, it has simply gone above its Total Design Power. When intel reports power usage, in particular power usage as needed by OEMs who design cooling solutions, it doesn't use the typical method of maximum theoretical power usage (which is the number AMD reports). Instead, it uses a power usage that is safely above what the majority of commone code paths will see (which is substantially lower than maximum, easing the burden on the cooling system designers and letting them tout lower effective power usage). The clock gating is their method of ensuring that the power doesn't actually go above their stated power level -- unfortunately, when this happens it is usually during some extremely intense computations that you don't really want to slow down by 50%. I've seen reviews of P4 parts which show the effects of this. It looks really odd unless you know what's going on under the covers.

Better article: no FUD-OpenBSD demo-Theo comment

[droopycom]

From : http://blog.ncircle.com/ [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

Re:Think like an evil hax0r, then be afraid.

[jmorris42]

> But how do you trigger a thermal alarm on a virtual machine (without access to
> the "real" OS)?

If it is a P-IV in a 1U rack I'd suspect all you would have to do would be chew CPU cycles like mad for a hour. It isn't that hard, most of the first batch of P-IV chips ran so hot they will only run at their rated speed for a few minutes without some serious aftermarket cooling solutions. So there are potentially a couple million machines out there which are especially vulnerable.

SMM isn't ring 0, it's ring -1

[(Score.5, Interestin]

What the replies here (and I think the presentation to some extent) have missed is that SMM isn't ring 0, it's ring -1. In SMM you can do things that the processor hardware normally prevents, like creating invalid/illogical page table entries. Since SMM bypasses any hardware-enforced checks, you can set the processor up to do... surprising things. This security risk was AFAIK first discussed in http://www.amazon.com/gp/product/0387953876/sr=8-1 /qid=1144813279/ref=sr_1_1/102-2091912-1657751?_en coding=UTF8 [amazon.com]