Next week's Thursday, March 19th, 1600 UTC, we will publish a paper (+ exploits) on exploiting Intel® CPU cache mechanisms.
The attack allows for privilege escalation from Ring 0 to the SMM on many recent motherboards with Intel CPUs. Interestingly, the very same attack will be presented by another researcher, Loic Duflot, at the CanSecWest conference in Vancouver, Canada, on... Thursday 19th, 1600 UTC. BTW, this is a different SMM-targeting attack than the one we mentioned during our recent TXT talk and that is scheduled to be presented later this year.
Here's the full story (there is also a moral at the end) …
Just after our presentation at the Black Hat last month, we (i.e. Rafal and I) have been independently approached by some person (or two different persons — we haven't figured that out actually — there were some ca. 30 people willing to ask us questions after the talk, so it's hard to remember all the faces), who was very curious about our SMM attacks (whose details we haven't discussed, of course, because Intel is still working on a fix). This person(s) started asking various questions about the attacks and one of the questions, that was asked to both me and Rafal, was if the attack used caching. Later that day, during a private ITL dinner, one of us brought this issue, and we started thinking if it was indeed possible to perform an SMM attack via CPU caching. By the end of the dinner we have sketched out the attack, and later when we got back to Poland, Rafal implemented a working exploit with code execution in SMM in a matter of just a few hours. (I think I used way too many parenthesis in this paragraph).
So, being the good and responsible guys that we are, we immediately reported the new bug to Intel (actually talking to Intel's PSIRT is getting more and more routined for us in the recent months ;). And this is how we learnt that Loic came up with the same attack (back then there was no talk description at the conference website) — apparently he approached Intel about this back in October 2008, so 3-4 months before us — and also that he's planning to present it at the CanSecWest conference in March. So, we contacted Loic and agreed to do coordinated disclosure next Thursday.
Interestingly, however, none of us was even close to being the first discoverer of the underlying problem that our attacks exploit. In fact, the first mention of the possible attack using caching for compromising SMM has been discussed in certain documents authored as early as the end of 2005 (!) by nobody else than... Intel's own employees. Stay tuned for the details in our upcoming paper.
Conclusion
If there is a bug somewhere and if it stays unpatched for enough time, it is almost guaranteed that various people will (re)discover and exploit it, sooner or later. So, don't blame researchers that they find and publish information about bugs — they actually do a favor to our society. Remember the guy who asked us if our attack used caching? I bet he (or his associates) also have had exploits for this caching bug, but apparently didn't notify the vendor. Hmm, what they might have been doing with the exploit? When was the last time you scanned your system for SMM rootkits? ;)
Anyways, congrats to Loic for being the first one who wrote exploits for this bug. Also congrats to Intel employees who originally noticed the problem back in 2005.
Friday, March 13, 2009
Subscribe to:
Post Comments (Atom)
15 comments:
Interesting research, as always ;>
"When was the last time you scanned your system for SMM rootkits? ;)"
This sentence has shaken me. My god, PCes are still getting owned by ring 3 malware, even simple ring 3 rootkits are still a problem for some. So I guess SMM rootkits will be just another thing that will be added to the growing list of unending security challenges ;>
Looking forward to the paper ;>
My god, PCes are still getting owned by ring 3 malware, even simple ring 3 rootkits are still a problem for some.
Yes, that's so true... And so disappointing at the same time...
BTW, the statement: "When was the last time you scanned your system for SMM rootkits?" was supposed to be a joke -- there are no such things as SMM scanners these days ;)
BTW, the statement: "When was the last time you scanned your system for SMM rootkits?" was supposed to be a joke -- there are no such things as SMM scanners these days ;)
And are there any SMM rootkits ? Some even-bluer-pill or sth ? ;>
Hehe anyway, yeah, I know, I had in mind the near future ;>
And are there any SMM rootkits?
Sure there are:
http://www.blackhat.com/html/bh-usa-08/bh-usa-08-speakers.html#Sparks
And are there any SMM rootkits?
Oh. Right. I've missed that one ;>
Thanks for the link ;>
@Othman: CPU cache exploiting has been used before in crypto attacks indeed, but I cannot remember any system privilege escalation attack using CPU caching. Can you provide appropriate links?
I'm sorry but where will it be published (The blog or the main web site)?
The paper will be published on the ITL website:
http://invisiblethingslab.com/itl/Resources.html
I will also post a link to the paper here on this blog.
So this is a Intel only cache bug or does this affect AMD as well?
@Bill: unfortunately we haven't got enough resources to thoroughly research this problem on the AMD-based systems. (Of course, if somebody is interested in sponsoring such a research, we would be interested in extending our research to also cover the AMD systems).
Can you tell if virtual environments would be effected by this?
What would you need to test under AMD environments?
What can we do using these SMM rootkits?
How did these infected computers connect to you?
I wonder if the method for reading SMM code described in the article does really work. I mean getting not only modified bytes but the code itself which is not modified.
I am curious because right now I am debugging an issue where SMI handler simply clears SMIs from watchdog thus rendering the watchdog useless.
@anonymous_who_asks_about_smm_reading_exploit:
The cache lines are filled not only on writes, but also on reads (instruction fetches).
Post a Comment