Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel CPU Privilege Escalation Exploit

Posted by timothy on from the they-never-offer-the-purple-pill dept.

Eukariote writes "A paper and exploit code detailing a privilege escalation attack on Intel CPUs has just been published. The vulnerability, uncovered by security researchers Joanna Rutkowska (of Blue Pill fame), Rafal Wojtczuk, and, independently, Loic Duflot, makes use of Intel's System Management Mode (SMM). Quote: "The attack allows for privilege escalation from Ring 0 to the SMM on many recent motherboards with Intel CPUs. Rafal implemented a working exploit with code execution in SMM." The implications of this exploit are severe."

3 of 242 comments (clear)

  1. Ring of Fire by goombah99 · · Score: 5, Interesting

    So it says you can promote from ring0 to SMM. So I take it that's a lower level of hell?

    If you are running in ring zero doesn't that mean by definition you are completely trusted anyhow?

    Or is the vision something like you enter your root password to install the cheeze-whiz app and the mal ware not only installs the code but escalates itself above the operating system.

    I think I'm not getting it.

    --
    Some drink at the fountain of knowledge. Others just gargle.
  2. Inexcusable by sjames · · Score: 5, Interesting

    Considering that SMM exists solely to help proprietary vendors hide the "secret sauce", this is inexcusable. Every legitimate use of SMM could be accomplished by telling the OS that the memory area is reserved without hiding it away.

    The most frequent use is to have a proprietary chipset device emulate a standard one without revealing the details of its operation.

    Often enough, the "big secret" is that the hardware is crippled and the CPU is doing the real work. Kinda like those onboard "RAID controllers" that are just a plain old IDE interface and a poorly implemented softraid in the proprietary driver. The next step from that is to hide the softraid in SMM and have an SMI trigger whenever the OS writes to the fake registers in the PCI space.

    1. Re:Inexcusable by Animats · · Score: 5, Interesting

      Often enough, the "big secret" is that the hardware is crippled and the CPU is doing the real work.

      Yes. And board manufacturers get really angry when someone detects that.

      In the QNX community, where "real time" really means something, there's a common test of the operating system's real-time response. The tester wires up a square wave generator to an input that will cause an interrupt, programs the computer to wait for the interrupt and start a real-time user process, and has the user process turn on an output. You run some program in the background to keep the CPU busy. On a serious real-time OS, this shouldn't hurt real time response, and on QNX, it doesn't. There are no long interrupt lockouts in the QNX microkernel. Drivers are interruptable user processes.

      Input and output lines are then wired up to a storage oscilloscope, to display the interrupt response. On most machines, the scope shows a nice, boring, consistent interrupt response time of a few microseconds. But on some CPU boards, there's a spike way out there from the expected delay period. This shows clearly the occasional huge delay (by real time standards) of hundreds of microseconds, maybe even more than a millisecond. That's because something is going on in System Management Mode. QNX programmers have found USB serial emulation, flash disk IDE emulation, and other crap running at SMM level.

      When a vendor gets caught doing this, word gets around in the real-time community that their board is unacceptable for real-time use. Vendors selling embedded system boards have been caught this way.

      Hard real time is a world in which stuff is expected to actually work every time.