Slashdot Mirror
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.'"
physical access means the h4x0rs can take over your computer now, news at 11.
What am I missing here? If they already have that much access to the system, aren't you already screwed?
someone could do the same with ANY interrupt handler... oh wait... an MMU would protect against that.
Physical access trumps all security. Everyone knows this. This really isn't news, just an interesting new exploit that happens to affect a lot of... systems that are already vulnerable from the same people in the same situation.
Move along, folks.
I pretend to know more than I really do by mooching off google and wikipedia.
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...
-*The above statement is printed entirely on recycled electrons*-
How is it that an unprivileged user can write to such a sensitive location in the first place?
Bogtha Bogtha Bogtha
I am so glad that we have legions of Security Experts to protect us against every possible Rube Goldberg attack out there. Thanks to their tireless commitment to security, I can sleep safer at night by knowing that no one will take a blowtorch to my processor, install custom software, and then override the security safeguards that they could have gotten through by booting into safe mode. These people are truly a God-send. </sarcasm>
Javascript + Nintendo DSi = DSiCade
Remember that old Good Times virus hoax? People who were In The Know knew that it was a hoax because it claimed that, just by opening it, it could physically destroy your computer.
:)
Then a few years later, Microsoft brought us Outlook with automatic attachment opening, making the first part possible, and now Intel has given us the potential for the second part.
Good Times apparently wasn't a hoax, it was just ahead of its times.
This attack would already require the malicious software to already be running on the machine and already have super-user access. Once you get there, it doesn't matter. The attack is worthless. Unfortunately, the article is short on details - so you can't tell if there is nothing to see, or if the report is just bad. I suspect there is nothing to see.
Along a similar vein, I have developed a martial art where I can kill anyone in one blow. It requires that my opponent is already tied-up, asleep, and I have a gun.
Pentium computers are vulnerable to baseball bats!
Seriously, if they have access then you are screwed anyways...
- Andrew
I meta-moderate because I care.
So, if I have a real firewall setup and I don't open every attachment I'm sent, I'm still safe, right? At the end of the day, you still have to run the exploit for it to work. So, how is that any worse than the rootkits running around at the moment? The vast majority of viruses still specifically depend on users who haven't hardened their systems.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
That's where this article gets a little sketchy.
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,
Ok, fine.
Every computer that runs on x86 chip architecture may be vulnerable to this attack
Wait. How did we get here?
Let's go through this, again. Intel Pentium 4s are hot. No surprise there. They enter special modes when overheating that may introduce a security vulnerability. Fine. How does this cross over to AMD and Via chips again? AMD and Via processors don't have special modes like that. 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 heatsink falling off.
So, how are all x86 chips vulnerable, exactly? (Incidentally, between this and this, AMD is really looking to be a much safer deal, not to mention faster, cooler, more power efficient, etc.)
Just went and RTFA, and I'm frustrated by a lack of hard details about the new threat:
:-(
- The article states that all x86 processors "could" be vulnerable. Does that mean the *entire* series of Pentium chips, even the older PIII and PII's? If so, are they equally as easy to compromise as the modern versions?
- There is no mention of AMD architecture. Doesn't AMD have an equivalent "overheat failsafe" halt-and-cooldown function? Wouldn't that make AMDs vulnerable to this type of exploit as well, or do they require a slightly different attack?
- Isn't the motherboard BIOS FlashROM responsible for the monitoring of and responding to dangerous CPU temperatures? Haven't they already been safeguarded against unauthorized writes, due to the Chernobyl virus?
I think I'll hold off on ordering the prototype Borg implants when they come on the market....
"All hands, BRACE FOR IMPACT!"
Karma: Chameleon (mostly due to the fact that you come and go).
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.
Let me get this right, by DoSing the proc someone can overwrite the embedded code on the chip? If someone already owned the box and were to use this, it sounds like it would be the ultimate rootkit. Place in the proc, then when the system is hardened/reloaded initiate another DoS (lots are available for winblows) and viola instant re-infected Zombie PC.
Or am I confused?
This reminds me of the vulnerability in the operating system that shipped with the Univac 1100/10. The checkpoint/restart facility allowed you to write a checkpoint image to tape. Part of the checkpoint image was the system status register.
The crack:
1. Checkpoint your job to tape.
2. remount tape.
3. fiddle the executive-mode bit in the dumped status register.
4. remount tape.
5. restart job -- mainframe p0wn3d.
Of course, in those days, a student that could do that was quickly hired into the system programming staff so that they could keep a closer eye on him and also get some productive work from him.
Ohh... BTW... if you can find an 1100/10 these days, it won't work any more. They fixed that about the same time they quit making CPU's out of vacuum tubes.
I wish Intel would create new bugs, instead of just repeating old ones. Copycats.
Just think, the script kiddies that pulled this off are now drawing Social Security.
Not only do you receive a convenient olfactory signal to alert you to the situation, but you also avoid security breaches brought on by overly complex thermal management.
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).
Computers allow humans to make mistakes at the fastest speeds known, with the possible exception of tequila and handguns
ALERT!
Pentium based machines are also vulnerable to a denial of service attack from a hacker with physical access to the machine and in the possession of a large axe. Should the attacker be wielding a pair of axes (one in each hand) then the attack would constitute a distributed denial of service.
Fear: When you see B8 00 4C CD 21 and know what it means
While I don't know the details of the security risk (if any); I do know quite a bit about system management mode.
SMM is present on many x86 processors and dates back to the days of NeXGen and Cyrix and 486s. It is basically a real-like mode of the x86 processor where certain hardware emulation type operations are performed.
The SMM software usually resides at A000:0000 which is normally video memory in a PC. However, in SMM the address decoder actually mapps those addresses to physical RAM and runs the SMM kernel to service various requests.
The types of requests that can cause entry to System Management mode are varied and depend on the implementation of the x86 processor. The CPU I am most familiar with is the National Semiconductor Geode series (now in the hands of AMD, I believe). This single-chip CPU behaved almost like a PC (when used with a few, low-cost companion parts). It did this without wasting silicon real-estate by emulating all the crazy ports and nonsense of a legacy PC with SMM software.
For example, there was a simple audio DAC wired up to the CPU. But you can make it look like a soundblaster by writing a virtual device driver. I/O to the sound blaster ports, DMA controller (well, brain-damaged ISA DMA controller), and memory mappings (if any) would result in traps to the SMM kernel, post a message into a queue which the SMM kernel would dispatch to a "soundblaster task" that figured out what you really wanted, maybe did some MMX arithmatic (hey, that chip had a real MMX unit!) and then shovel data to the DAC.
Software was none for the wiser and the hardware could be simple rather than a big legacy emulation machine.
SMM actually had its origins in laptops to handle power management tasks -- long before operating systems knew about power management.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Having said that, I believe B3 security mandates that memory and other system resources have mandatory access controls for precisely this sort of reason - a user who already has system access would then be unable to exploit that to gain control of other parts of the computer. Typically, such containment is through hardware, so unless you embedded a suitable driver into the virus code, interrupting the OS wouldn't gain you anything.
On a side-note, the Broadcom Sentosa system (based on the BCM1250 processor) has a bug such that any fast maths routine will reboot the system. Explains why a lot of people hate Broadcom.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
It happened to my wife's computer. The case is behind her desk, so I'm pretty sure nobody was picking it up and dropping it. One day it started spontaneously turning off after only a few minutes of use. After a little frustration at not even being able to complete any diagnostics on my CD, I finally pulled the desk out and opened the case up. I found the heatsick hanging from one peg, and the strength of the spring arm caused the heatsink to be held away from the CPU. It turned out that the lower peg (a stub of plastic poking out of the base of the CPU socket) had broken off. Repairing that was a pain; those heatsick spring arms are strong! I finally epoxied the arm to the base and weighted it down with a screwdriver wedged under a board with 6 bricks on top. The next day, it was working as good as ever.
Edward Burr
Having a smoking section in a restaurant is like having a peeing section in a swimming pool.
> 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.
People, think this through a bit and some more dangers appear. If root can replace System Management Mode there are some interesting possibilities for evil. SMM runs at permission levels beyond ring0, think of it as ring-1. From there you can escape any virtualization, any chroot jail, probably even escape from inside an emulator like VMWare if you can manage to execute the exploit without the emulation catching it and simulating it. Until this is completely understood and fixed, Xen, usermode linux, chroot and possibly VMWare/VirtualPC should be suspect.
Now imagine just how many people have root access to their virtual server at a hosting company and how many other users are running on the same physical hardware secure in the belief that their customer information is safe. But is it?
Democrat delenda est
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
:P
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.
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.
The enemies of Democracy are
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
Come to think of it, I had an old HP that integrated a fan controller on the motherboard. It might have been hardware-only, though.
Seems like a lot of hacking for a small payoff, but I think the path is there for some systems.
But it looks like there may be something real here.
The presentation lists events that will trigger a System Management Interrupt (SMI) and enter System Management Mode (SMM). Overheating is only one of them. Another is "century rollover". Taken literally, that would mean that anyone who could set the clock to 11:59 December 31 1999 [I'd say 2000 but I doubt the chip is mathematically correct] can enter SMM without needing physical access to the machine or to the circuit breaker for the air conditioning. Or to use the presentation's example, outl(0xB2, 0x0000000F);.
If I read this problem report correctly, then a process outside of SMM can write to the memory for SMM. (Controlled by the D_OPEN bit in the SMM control register).
So it looks like you can do it without physical access, where "it" is a privilege escalation that *starts* from root. That's getting less absurd all the time as virtualization and technologies like SELinux become more common. Also allows planting a deeper-than-root rootkit. You could escalate to God of Hardware or in the CanSecWest example to "root at securelevel -1".
Maybe I should email Duflot for details and write up something for my nerdish security blog
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
How are you able to any of those sequence of operations if you are not *already* executing as root or as ring 0? If you already have control of ring 0 and/or root, you can do what you want to the computer already. SMM doesn't get you anything special, except perhaps the ability to mess with internal processor states you can't normally (make writable code segments in protected mode, for example).
By the way, whenever the CPU does a memory read or write while in SMM, it asserts the SMM# pin. This means that the hardware is fully able to consider SMM RAM to be totally separate from the main memory space - but most implementations don't. In fact, SMM has an instruction called "umov" that allows SMM hypervisors to read/write the main memory space. (umov is equivalent to mov when not in SMM.)
If it's *really* a problem, change the motherboard, not the CPU. The motherboard can physically lock out the SMM memory space from even kernel programs if it so desires.
Melissa
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager