Monday, January 05, 2009

Attacking Intel® Trusted Execution Technology



Press people: please read our press release first and also refer to the disclaimer at the end of this blog post. Thank you!

Update: 1/5/2009 19:21 CEST: minor typos/spelling corrections. Thanks to Jarred for point out some of the typos.

A word about Trusted Computing
The term Trusted Computing and related technologies, like Palladium, Trusted Platform Module, LaGrande, have always caused lots of controversy in the IT world. Most of the fear, however, has been a result of the lack of understanding of how a particular technology really works.

Nevertheless, Trusted Computing is becoming part of our lives, whether we want it or not. These days almost every new laptop comes with an on-board Trusted Platform Module (TPM). Microsoft's Palladium initiative have been renamed so many times in the recent years, that probably even people working at Microsoft are confused now. Nevertheless, some of the Palladium technologies made their way into Vista, and Microsoft BitLocker is, without doubt, the most successful, widely deployed product that is based on the idea of Trusted Computing. (In fact the Bitlocker is the only one thing that I really have been missing since I switched from Vista to Mac some time ago).

On the hardware side, besides the famed TPM, we also have had the LaGrande technology, that is often connected with things such as Remote Attestation, Protected Execution and other scary terms…

A word about Trusted Execution Technology
LaGrande, recently renamed Trusted Execution Technology (TXT), is Intel's response to the Trusted Computing trend. TXT is currently part of the vPro™ brand, and for about a year now users can buy a vPro/TXT compatible hardware in regular computer stores (the first one was the DQ35J desktop board with certain Core 2 Duo processors, which I was able to buy at the end of 2007 — remember that TXT requires support from both the CPU and the chipset).

TXT is not an alternative to TPM, in fact TXT heavily relies on the TPM to provide basic services like e.g. secure storage of measurements done by the TXT. Also, Palladium, or whatever it is called these days, is not a competition to TXT. Intel TXT can provide building blocks to e.g. Vista Bitlocker, arguably making it more secure then it is now (Current Bitlocker implementation, AFAIK, relies on a so called Static Root of Trust for Measurement, which requires TPM, but not TXT).

What kind of measurement would TXT like to store in our TPM? Well, the whole TXT is, in fact, all about making and storing software measurements, or, using a more familiar language, secure hashes of certain software components.

The sole purpose of Intel TXT technology is to provide a trusted way for loading and executing system software, e.g. Operating System kernel or Virtualization Machine Monitor. What is extraordinary here is that TXT doesn't make any assumptions about the state of the system before loading the software, thus making it possible for a user to ensure secure load of an OS or VMM, even in a potentially compromised machine.

In other words, our system can be all full of boot sector viruses and BIOS rootkits, and god-knows-what-else, and still TXT should allow to load a clean VMM (or OS kernel) in a secure way, immune to all those rootkits present in the system in a moment just before the load process. This TXT-supported load process is called Late Launch, and is implemented via a special new CPU instruction called SENTER.

It's a good place to mention that AMD has its own version of the late launch implemented via SKINIT instruction. We haven't looked at the AMD technology thoroughly yet, so I will refrain from commenting on this.

The late launch is a pretty amazing thing, when we think about. It promises to effectively provide all the benefits of a computer restart without actually restarting it.

It is hard to overemphasize the potential impact that a technology such as TXT could have on computer security. One can immediately see that it could eliminate all the system-level persistent malware — in other words we can easily build systems (VMMs or even standard OSes) that would be immune to attacks that try to compromise system binaries on disk, or attack the system right from the bootloader or BIOS. Combining this with VT-x and VT-d technologies, system developers (for the first time, at least as far as the "PC" platform is considered) have gotten extremely strong tools into their hands that should allow them to create really secure VMMs and OSes…

Hopefully by now, my Dear Reader, you should have the feeling what kind of an animal Intel TXT is and how desperately the world needs it...

And now, we are going to move on and show practical attacks on current TXT implementations... :)

Attacking Intel TXT!
Ok, not in this post today, but rather at the upcoming Black Hat conference in Washington, DC in February. Over the recent months, Rafal and I have been looking at the Intel TXT technology as part of a work done for a customer, to see if this could be used to improve security of a product, from a typical user's perspective. We figured out that it definitely could, but that there are also some issues…

And those "issues" gave us a starting point in developing a proof-of-concept (albeit very reliable) exploit that shows how we can bypass trusted boot process implemented by Intel's tboot.

Tboot, which is also part of (scroll down to the end of the page) the Xen hypervisor, can be though of as a reference implementation of TXT-based system loader, that could be used to securely load either the Xen hypervisor or the Linux kernel, when run on a vPro/TXT compatible hardware.

[copy-and-paste from the press release follows]

Our attack comprises two stages. The first stage requires an implementation flaw in a specific system software. The second stage of the attack is possible thanks to a certain design decision made in the current TXT release.

While evaluating the effectiveness of the Intel® TXT technology, as part of a work done for a customer, we have identified several implementation flaws in the Intel's system software, which allowed to conduct the above mentioned stage-one attack. We have provided Intel with extensive description of the flaws in December 2008, and Intel is currently working on fixing those vulnerabilities.


We have also been in touch with Intel about the possibility of conducting the second-stage attack since November 2008. In December, after providing Intel with the details about the first-stage attack, Intel promised to release, in the coming weeks, an updated TXT specification for developers that would explain how to design their TXT-based loaders in such a way that they are immune to our attack. Intel claims the current Intel® TXT release does contain the basic building blocks that could be used to prevent our second-stage attack and the release of the additional specification would make it feasible in practice.


More details in February in DC :)

TXT useless?
Some people are skeptical about the TXT technology, and not only because of the Irrational Fear of the Trusted Computing (IFTC), but rather because they point out to the complexity of the whole technology. The complexity is bad, because 1) it leaves more space for potential attacks, and 2) it discourages developers (ISVs) from using the technology in their products (e.g. neither Microsoft, nor VMWare make use of TXT in any of their bare-metal hypervisors, even though TXT is very well suited for this kind of software).

It is true that TXT is a very complex technology (the SENTER instruction is probably the masterpiece of the CISC architecture!), but I personally like it. In my opinion this is the first technology available for the PC platform that has the potential to really change something, much more then the NX-feature did a few years ago. Before people will run to the comment box — if you would like to argue about the usefulness/uselessness of Trusted Computing/TXT, please base your opinions on technical facts (read the spec!) and not on your feelings!

Disclaimer (for press)

Starting January 2009, we (at Invisible Things Lab), decided to issue press releases in addition to this blog. The general rule is: press releases are written for journalists, while the blog is mainly written for other researchers, security enthusiast, etc.

The wording of our press releases is carefully chosen to minimize the potential of a possible misinterpretation. The press releases carry less information, but, we think, are better suited for a more general public, that doesn't have background in computer science, programming and security.

The blog is written in a much more casual way, without thinking for half an hour on every sentence. The articles on this blog might present some facts as extremely exciting, because e.g. for me, a person deeply involved in a system-level security research, they indeed might be very exciting, which might not be the case for a general audience. I sometimes might also use shortcuts, metaphors, or irony, and other figures of speech, that might not necessarily be obvious for a more general public.

If you are a journalist and you think you just found something very sensational on my blog, I would suggest that you double-check with me, before writing about it.

Thank you for your cooperation.
Joanna Rutkowska,
Founder and CEO,
Invisible Things Lab.

7 comments:

Peter J. Cranstone said...

You should check out Secure64's offering. (www.secure64.com) They have a secure operating system that is immune to tampering. (Disclaimer: I'm the founder of the company, although I'm no longer there.)

Cheers,

Peter Cranstone
CEO 5o9 Inc

rehevkor5 said...

Irrational Fear? Sounds like a Baseless Hyperbole to me.

Mike Hearn said...

I'm glad somebody in the non-corporate security community is willing to stand up for TC. I've been interested in this technology for a long time, and have recently given a tech talk on it here at Google, but a lot of people hear the words "trusted computing" and switch off.

BTW I think the reason Microsoft and VMware don't use TXT is that it's really not ready yet. The tboot reference implementation still requires quite obscure hardware and BIOS reflashing to work properly, and TXT doesn't yet provide any trusted I/O, making it useless for a large/interesting set of applications.

joanna said...

@Mike: The tboot versions we played with (recent ones) do not require any BIOS reflashing, at least on Q35 Intel boards. I would expect any fairly recent BIOS to support TXT as well.

Trusted I/O -- I assume you mean Protected Input/Output as it is called in The Grawrock's Book -- this is sort of an additional mechanism and I'm not even sure if it will make it to the TXT anytime soon. Protected In/Out, as I understand it, is more a DRM-like thing, rather then something for building secure VMMs/OSes.

I think that current TXT + VT-x + VT-d has already excellent potential, even without this Protected Input/Ouput feature.

SunCatIv said...

Nice post, Thank You For Sharing

Anonymous said...

Hey Joanna,
Really interesting stuff, but I think the attack is based on the OS loader and how the tboot is actually launched during the boot process... still lots more to read I guess lol..

joanna said...

@anonymous: nice to see people start speculating about our attack, although you're totally wrong in your guess :P As I wrote, the attack is fairly generic and doesn't depend on the particular implementation of the loader, e.g. tboot. In other words, tboot will not have to be patched to prevent the attack.