Flaw in the design makes virtualisation a security risk - but to who?
When you're dealing with architectures on a microscopic scale, eventually you run into problems, and that's what Intel has faced quite often.
From Translation Lookside Buffer bugs to lawsuits and unpleasantness, Intel has had their share of problems already, but this one affects the security of all of their CPUs out today.
Discovered by Johanna Rutkowska at Invisible Things Lab, there is a loophole in the CPU design that allows a program to access the second ring of the operating system (where the drivers are loaded).
While this doesn't sound too bad, it gives the program essentially free reign over the hardware, and is buried deep enough that simple virus scans can't detect it.
Arstechnica provides a very nice summary of how this is achieved:
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...)."
Basically tricking the system into thinking that the corrupted data will allow other code to run without too much worry.
Intel is working on fixing it however, and while this security flaw might seem quite terrible, it also is rather tricky to exploit en masse, so your rig will probably survive for just long enough for Intel to patch it through a BIOS update.
Issue: 133 | February, 2012