Intel CPU-level exploit could be tempest in a teapot
On Thursday, Invisible Things Labs released details on a new, CPU-level exploit that could be used to execute software on a permission level far below that of any standard operating system. Is this a major problem for Intel, or an issue of merely academic interest?
By Joel Hruska | Last updated March 20, 2009 8:25 AM CT
Johanna Rutkowska of Invisible Things Lab has been making headlines ever since she announced her development of a seemingly undetectable rootkit she dubbed "Blue Pill." While that project is now defunct, Rutkowska has continued her research into hardware virtualization technology. Her more recent efforts have focused on Intel platforms and the company's Trusted Execution Technology; Intel released a BIOS update to fix several security vulnerabilities Invisible Things Lab discovered back in August of 2008. On Thursday, March 19, Rutkowska and fellow team member Rafal Wojtczuk released details of yet another Intel-focused exploit—is the CPU manufacturer's security sandbox not up to snuff?
Before we discuss the flaw in particular, let's take a quick moment and review the ring security model. The term "ring" refers to protective rings that encircle the OS kernel. Ring 3 (defined as "Applications" in the diagram below) is where users and programs should spend the vast majority of their time. Applications should never need access to Ring 0 or kernel mode, as it amounts to writing the application a literal carte blanche to modify, change, or delete anything it wants. One of the features Intel's Vanderpool (VT) technology offers is the ability to virtualize an OS starting from what we might call "Ring -1." An OS launched from Ring -1 can therefore run its own Ring 0 operations and is more effectively sandboxed from the host operating system.
The exploit Rutkowska unveiled (PDF) yesterday affects System Management Mode (SMM); the security team describes SMM as equivalent to Ring -2. Code operating this deep could do virtually anything, all while operating on a level too deep for an OS-level scan to reasonably detect. Access to this mode and the memory block where it's stored (known as SMRAM) is therefore extremely restricted. The memory controller is configured to lock SMRAM access exclusively to the BIOS, which then copies the SMM code into SMRAM. Once that copy is complete, the BIOS disallows all further access/modification requests that originate from outside the SMM memory block. Because the SMM module operates at Ring -2, no other program, hypervisor, or OS kernel has sufficient authority to access the memory block.
Accessing the inaccessible
Invisible Things Lab provides a step-by-step guide to this attack; I'll only summarize it here. An attacker who wishes to modify the code within the SMM must first locate the SMRAM region within system memory and designate it as a write-back cache. Once the address range is properly specified, our hypothetical hacker "creates write accesses to the SMRAM's physical address range." Because the space as been previously set as WB cacheable, the accesses are cached rather than rejected. Next, the attacker triggers a System Management Interrupt (SMI), which orders the CPU to enter System Management Mode and execute the code therein. The CPU drops into SMM happily enough, but when it fetches code from SMRAM, it fetches the corrupted cached data first. The result, says Rutkowska, is that "the above scenario allows for arbitrary SMM memory overwrite (and later code execution...)."
Intel continues to work on resolving these security issues. Senior Intel spokesperson George Alfs told Ars, "We are working with these researchers. We take this research and all reports seriously. Currently as far as we know, there are no known exploits in the wild." Invisible Things notes that the company claims to have solved the problem in later chipsets, but that shipping DQ35 models are still affected.
Truthfully, there's precious little reason to panic, particularly given the fact that Invisible Things believes an attacker would need a great deal of time and in-depth information on a particular system configuration in order to launch the type of attack described above. For all the furor surrounding the idea of a chip or chipset-level vulnerability, the chances of a general exploit going wild is virtually nil. General exploits thrive on commonalities; Rutkowska's SMM assault requires extreme specificity. It is, however, important that Intel take these issues seriously as the company appears to do. The complexity of computer security is such that seemingly low-level, unimportant flaws can be combined with higher-level problems, and suddenly spawn something far more ugly and massive. The only approach is to lock every gate—particularly when you're selling a platform based entirely around the idea of "trusted" computing.
http://arstechnica.com/security/news/2009/03/storm-over-intel-cpu-security-could-be-tempest-in-a-teapot.ars
On Thursday, Invisible Things Labs released details on a new, CPU-level exploit that could be used to execute software on a permission level far below that of any standard operating system. Is this a major problem for Intel, or an issue of merely academic interest?
By Joel Hruska | Last updated March 20, 2009 8:25 AM CT
Johanna Rutkowska of Invisible Things Lab has been making headlines ever since she announced her development of a seemingly undetectable rootkit she dubbed "Blue Pill." While that project is now defunct, Rutkowska has continued her research into hardware virtualization technology. Her more recent efforts have focused on Intel platforms and the company's Trusted Execution Technology; Intel released a BIOS update to fix several security vulnerabilities Invisible Things Lab discovered back in August of 2008. On Thursday, March 19, Rutkowska and fellow team member Rafal Wojtczuk released details of yet another Intel-focused exploit—is the CPU manufacturer's security sandbox not up to snuff?
Before we discuss the flaw in particular, let's take a quick moment and review the ring security model. The term "ring" refers to protective rings that encircle the OS kernel. Ring 3 (defined as "Applications" in the diagram below) is where users and programs should spend the vast majority of their time. Applications should never need access to Ring 0 or kernel mode, as it amounts to writing the application a literal carte blanche to modify, change, or delete anything it wants. One of the features Intel's Vanderpool (VT) technology offers is the ability to virtualize an OS starting from what we might call "Ring -1." An OS launched from Ring -1 can therefore run its own Ring 0 operations and is more effectively sandboxed from the host operating system.
The exploit Rutkowska unveiled (PDF) yesterday affects System Management Mode (SMM); the security team describes SMM as equivalent to Ring -2. Code operating this deep could do virtually anything, all while operating on a level too deep for an OS-level scan to reasonably detect. Access to this mode and the memory block where it's stored (known as SMRAM) is therefore extremely restricted. The memory controller is configured to lock SMRAM access exclusively to the BIOS, which then copies the SMM code into SMRAM. Once that copy is complete, the BIOS disallows all further access/modification requests that originate from outside the SMM memory block. Because the SMM module operates at Ring -2, no other program, hypervisor, or OS kernel has sufficient authority to access the memory block.
Accessing the inaccessible
Invisible Things Lab provides a step-by-step guide to this attack; I'll only summarize it here. An attacker who wishes to modify the code within the SMM must first locate the SMRAM region within system memory and designate it as a write-back cache. Once the address range is properly specified, our hypothetical hacker "creates write accesses to the SMRAM's physical address range." Because the space as been previously set as WB cacheable, the accesses are cached rather than rejected. Next, the attacker triggers a System Management Interrupt (SMI), which orders the CPU to enter System Management Mode and execute the code therein. The CPU drops into SMM happily enough, but when it fetches code from SMRAM, it fetches the corrupted cached data first. The result, says Rutkowska, is that "the above scenario allows for arbitrary SMM memory overwrite (and later code execution...)."
Intel continues to work on resolving these security issues. Senior Intel spokesperson George Alfs told Ars, "We are working with these researchers. We take this research and all reports seriously. Currently as far as we know, there are no known exploits in the wild." Invisible Things notes that the company claims to have solved the problem in later chipsets, but that shipping DQ35 models are still affected.
Truthfully, there's precious little reason to panic, particularly given the fact that Invisible Things believes an attacker would need a great deal of time and in-depth information on a particular system configuration in order to launch the type of attack described above. For all the furor surrounding the idea of a chip or chipset-level vulnerability, the chances of a general exploit going wild is virtually nil. General exploits thrive on commonalities; Rutkowska's SMM assault requires extreme specificity. It is, however, important that Intel take these issues seriously as the company appears to do. The complexity of computer security is such that seemingly low-level, unimportant flaws can be combined with higher-level problems, and suddenly spawn something far more ugly and massive. The only approach is to lock every gate—particularly when you're selling a platform based entirely around the idea of "trusted" computing.
http://arstechnica.com/security/news/2009/03/storm-over-intel-cpu-security-could-be-tempest-in-a-teapot.ars
Facebook
Twitter
Instagram