New SMM exploit targets Intel CPU caching vulnerability

This one delves pretty deep into head-scratching territory, but it looks like the folks at Invisible Things Lab have discovered an exploit that could open the door to some potentially serious attacks on certain Intel CPUs paired with some popular motherboards. Of course, the exploit that they've actually released is completely harmless, but it demonstrates that the CPU cache can be "poisoned" to let folks read and write into the otherwise protected SMRAM memory. As NetworkWorld notes, that could lead to some more nefarious folks developing a SMM rootkit, which would be all the more perilous considering that the user of the infected computer would have no way of detecting the attack. For its part, Intel is apparently well aware of the problem, and it has already fixed the vulnerability on some newer boards like the DQ45, but others still in widespread use (like the DQ35 pictured above) have seemingly been left hanging waiting for a fix of some sort.
[Via Network World, thanks Andrew]






















That's pretty inventive. It's amazing that hackers find vulnerabilities in some of the more deep hardware-level parts of a computer. It's just stupid when they use such vulnerabilities to needlessly cause havoc.
I wonder if this just affects intel boards?
So which is the vulnerable one here; the CPU or the motherboard?
It appears to be a combination of both, but mainly on the motherboard side.
"CPU cache can be "poisoned""
I blame the processor.
Wasn't SMM replaced when the Core 2's and i7's came out?
What's your point? That he (Jan) had a sex change? So what?
Makes me glad I just went with an Intel board for my new build!
Another "feature."
That's so awesome. It's the perfect security flaw. The world is ours!
Down with x86 down with viruses ....Long Live ARM!!!
actually this exploit is only available for code running in ring 0 meaning an operating system or hypervisor, if a process has that kind of access to the processor on a computer with a regular OS you're screwed anyway. the big deal is when running hypervisors with VM's that might compromise the host and take control over other VM's. not a good thing for large virtual environments like amazon's and microsoft's cloud services. so unless you're running hypervisors i'd go back to sleep.