Pentium Computers Vulnerable to Attack? 227
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.'"
Aren't you already screwed? (Score:5, Interesting)
Which x86 processors? (Score:1, Interesting)
Re:Sensational headline about a poor article. (Score:5, Interesting)
FCW stands for Federal Computer Week, a trade rag that US gov't stooges use to figure out how to best waste our tax dollars of shiny boxes with blinky lights. Their topic headings include the buzzwords:
The anonymous submitter might do well to remain so. Scuttlemonkey, OTOH, may have to enter the witness protection program. He's getting as bad as Zonk.
UNIVAC had similar vulnerability in checkpoint (Score:4, Interesting)
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.
Re:But how? (Score:2, Interesting)
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.
Technically, you are correct. (Score:3, Interesting)
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.
Re:FUD? (Score:3, Interesting)
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.
Think like an evil hax0r, then be afraid. (Score:5, Interesting)
> 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?
Re:Wait wait wait (Score:3, Interesting)
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.
It's a frustrating article (Score:4, Interesting)
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 [monkey.org] 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 [berylliumsphere.com]