Tuesday, December 06, 2011

Exploring new lands on Intel CPUs (SINIT code execution hijacking)

Today we're releasing a new paper where we describe exploiting a bug in Intel SINIT authenticated code module that allows for arbitrary code execution in what we call an “SINIT mode”. So, to the already pretty-well explored “lands” on Intel processors, that include ring 3 (usermode), ring 0 (kernelmode), ring “-1” (VT-x root), and ring “-2” (SMM), we're now adding a new “island”, the SINIT mode, a previously unexplored territory inhabited so far only by the Intel-blessed opcodes.

What is really interesting about the attack are the consequences of SINIT mode hijacking, which include ability to bypass Intel TXT, LCP, and also compromise system SMRAM.

It's also interesting how difficult was this vulnerability for Intel to patch, as they had to release not only updated SINIT modules, but also updated microcode for all the affected processors, and also work with the BIOS vendors so they release updated BIOSes that would be unconditionally loading this updated microcode (plus provide anti-rollback mechanisms for both the BIOS and microcode). Quite an undertaking...

You can get the paper here.

Intel also published an advisory yesterday, which can be downloaded from their website here. The advisory is peculiar in a few ways, however...

First, the advisory (I'm referring to the revision 1.0) never explicitly mentions that the attack allows to bypass TXT launch itself, only that the attack “may compromise certain SINIT ACM functionality, including launch control policy and additionally lead to compromise of System Management Mode (SMM). Intel also recommend to disable TXT altogether in the BIOS, as a preventive measure, in case the user doesn't “actively running Intel® TXT”... This reminds me how various vendors started actively disabling Intel VT-x after certain virtualization rootkits have been demonstrated some 5 years ago, and how many laptops still ship with this technology disabled today (or VT-d at least) to the questionable delight of many users.

Second, the advisory assigns only an “Important” rating to this vulnerability, even though another Intel advisory, published some two years ago for a problem also reported by us, and which which was strictly a subset of the current vulnerability in terms of powers that it gave to the attacker (in other words the current vulnerability provides the attacker with everything that the previous one did, plus much more), was given a “Critical” rating... This is called evolution, I guess, and I wonder what would be considered critical by Intel these days?

UPDATE (Dec 7th, 2011): Intel has just released an updated advisory (release 1.1) that now explicitly states that the vulnerability also bypasses Intel TXT.

This is the last paper co-authored with Rafal Wojtczuk, who recently decided to try some new things and to leave ITL. Rafal has been the most talented exploit writer I have worked with, and I will surely miss his ingenious insights, such as e.g. how to practically win an absolutely hopeless race condition with ICMP-delivered MSI! But then again, how many times can one break Intel technologies, before getting bored? At the same time ITL is really transforming now into a development company, with all our efforts around Qubes and architecting, rather than on breaking. I wish Rafal all the best with his new endeavors, and thank him for all the excellent contributions he made while working for ITL over the past 3+ years.

6 comments:

  1. Hey,

    Great find and a cool paper - had fun reading it :)

    Good work, as always :)

    As for the fix - so BIOS needs to be trusted now and load the microcode update for current CPUs, right?

    Cheers,

    ReplyDelete
  2. @Gynvael:

    Correct, all the current platforms must now trust the BIOS, and so it is now part of the TXT's TCB.

    Future platforms will not need a microcode update, and so they won't need to trust the BIOS for TXT.

    Glad you liked the paper :)

    ReplyDelete
  3. Hello Joanna,

    Looks like you had some discussion with Intel regarding the STM. Did they said anything about what they intend to do? Any insight whether they still believe it will come? What are they waiting for? Seems like this new paper is putting a lot more pressure on it.

    Again, nice work (Rafal and you).

    ReplyDelete
  4. I have a suggestion for Rafal.

    He should jump on the other side and send his résumé to Intel to show them how to fix their TC implementation. ;)

    ReplyDelete
  5. @Danny: Even if I had some discussion with Intel, I doubt I would discuss it publicly.

    ReplyDelete
  6. @Danny: I don't think Rafal needs to send his resume to anybody... When you're at this level it's the employers who send their offers to your inbox ;)

    ReplyDelete