Intel Patches Flaws In Trusted Execution Tech

An anonymous reader writes "Joanna Rutkowska's company Invisible Things Lab has issued the results of their research into flaws in Intel's Trusted Execution Technology (TXT), whose function is to provide a mechanism for safe loading of system software and to protect sensitive files. ITL describes how flaws in TXT can be used to compromise the integrity of a software loaded via an Intel TXT-based loader in a generic way, fully circumventing any protection TXT is supposed to provide. The attack exploits an implementation error in the so-called SINIT Authenticated Code modules and that could potentially allow a malicious attacker to elevate their privileges. Intel has released a patch for the affected chipsets, which include the Q35, GM45, PM45 Express, Q45, and Q43 Express." Here are ITL's press release (PDF) and Intel's advisory.

Comments

TPMs and related tech

[girlintraining]

It was true fifty years ago, and it's still true today: If I have access to the hardware, you're screwed. And thus far, there have been precious few non-trivial applications that have been unexploitable remotely at some point. Systems are amazingly complex and full of flaws because almost all modern software was built with security as an after-thought. The only difference these days between a "secure" system and an insecure one is that the secure system hasn't had its flaws discovered yet.

Re:TPMs and related tech

[pclminion]

It was true fifty years ago, and it's still true today: If I have access to the hardware, you're screwed.

Hardware safety is like thread safety. It originates at the lowest levels and percolates upward. In thread safety, the lowest levels are primitives like interlocked exchange. On top of this, we build spin-locks. On top of those we build critical sections. Etc. Hardware can be made secure by making it tamper-resistant. Cryptographic ICs can be rigged to self-destruct when somebody opens the package. Given a secure cryptographic chip, hardware security can be assembled on top of it. I'm not willing to go out on a limb and say that we have TRULY secure cryptographic chips, but if and when we do, we can built unconditionally secure hardware on top of them just like we build thread safety out of interlocked exchanges.

Re:TPMs and related tech

[Anonymous Coward]

Systems are amazingly complex and full of flaws because almost all modern software was built with security as an after-thought.

Please note that Unix was designed from the ground up to be secure,

No it wasn't - it was built to be open, used by mutually-trusting users.

You're thinking of Multics.

Re:TPMs and related tech

[dpilot]

The issue isn't to build perfectly secure hardware/software, it's to build *sufficiently* secure hardware/software. There really are self-destructing crypto-chips, but those are usually installed in critical hardware where the data involved is sufficiently concentrated and/or valuable that it's worth spending the extra money to protect.

Let's take a simple testcase... Assume that you want to use crypto-stuff to theft-proof your laptop by turning it into a brick for anyone who doesn't have the secret password/token. In bygone days, that might have been the BIOS password, but it's really simple to remove the battery, etc. That's a simple, cheap way to work around the protection. Many systems have a hard drive password, so let's pretend that it's secure. So the "cost" to steal one of those is a new 2.5" hard drive. Now as the protection becomes more sophisticated, presumably the cost to work around it rises as well. At some point, you're better off buying a new laptop, instead of breaking the protection on a stolen one.

Similarly with the value of the data. Most of my data is only valuable to me, not to anyone else. So for the most part, it's not worth much to someone else to crack my data protection. It's worth investing some money/resource to protect my data, but why would anyone bother working really hard to get at it? On the other hand, the previously mentioned mainframe may well have hundreds of thousands of credit card or account numbers, or it may have account numbers for lines of credit worh millions of dollars, etc. It's worth much more to crack the mainframe than it is my piddly system.

So while we may talk about how anything can be broken with physical access, most of the time, especially for Slashdotter's systems, it's just not worth the effort. What we can get off the shelf, TPM or TXT, etc, is probably good enough, probably even overkill.

Chipset patch?

[Christopher_Wood]

Do I have to weld it on or something?

Re:Chipset patch?

[DigiShaman]

Yes. Below is a video tutorial on how to do it.

http://www.youtube.com/watch?v=wJpukz5sn_U

Readme.TXT

[marciot]

User: Oh, look, someone sent me a text file
User: *double-click*
Computer: Launching trusted executable...
Trojan: Got ya, sucker.

Seriously Intel, TXT? What were you thinking?

Re:Readme.TXT

[mirix]

Yeah really. Some dude in his Intel office:
"Hey Jim, you know what computing needs? more ambiguous acronyms. That would be just grand."

Re:Readme.TXT

[Tycho]

The classic MacOS had a feature similar to this, but it was abandoned by MacOS X. One type of metadata present for each file in the classic MacOS had a four character creator code and another four character file type code. The FourCC codes used currently in audio and video files were originally derived from this system. At any rate, unless the file type was "APPL" or "CNTL" it wasn't going to execute from the Finder unless the file type code was changed, a nontrivial, but not an impossible task for a user aiming to do something stupid. "APPL" and "CNTL" were obviously not file types assigned to files by any web browser by default unless the browser decoded the .hqx or .bin file automatically and determined the resultant file was an application. Executables in the Classic MacOS needed to be encoded specially due to the unusual structure of executable files. Files had two forks, a resource fork and data fork and each fork had critical parts that were needed for an executable to run as well as being separate, distinct structures in the filesystem. A file downloaded from the internet would be stored entirely as a data file with all of the data in the data fork and without any data in the resource fork and thus impossible to execute on its own without some sort of rearrangement by another application. Granted the file could still have a trojan, and while a file freshly downloaded off the internet with a .mp3 extension could be double clicked the file would be opened by iTunes. Assuming or course that the filetype codes were set by the browser automatically after detecting the file extension, but iTunes would puke on the file after realizing it was not mp3 audio. An enterprising idiot could still decode the same trojan into an application with StuffIt even if the file contained a .mp3 extension to the file name and run it, but you really would have to work hard to be that stupid.

Currently however, one operation that might be useful that could be performed by a browser or a real-time scanner would be to check the contents and structure of the file to make sure it at least appears to match the a file of the same extension that matters to the OS and throw up a warning if the file is bad. Finding and alerting the user when the string "This program cannot be run in DOS mode" in a file in Windows or when the signature of an ELF or Mach-O binary appears unexpectedly in a file, might help. The problem I see is that while there are some techniques that could be implemented from the classic MacOS to improve the security of downloaded files, the changes would require reworking of the ABI (Application Binary Interface) among many other changes to both Windows and Linux to be workable. The compatibility issues that would crop up due to any major changes would be no fun either.

Re:WTF are you doing?

[Darkness404]

And once again... an XKCD reference comes in handy. http://xkcd.com/322/

None of the above

[hwyhobo]

What, you mean a woman is actually doing something useful involving computers? She must be fat, old, ugly, or all three.

None of the above: http://invisiblethings.org/about.html - she is young and rather attractive.

Not Trusting The User

[Anonymous Coward]

TXT is not about trusting you the user, its about not trusting you. You cannot be trusted not to copy that DVD or BluRay, so Intel and the media companies are arranging to take over your computer. With TXT installed you will not be allowed to do certain operations, and there will be no way around it even with administrator privileges. TXT is about taking away control of your computer and giving it to the big corporations. Only signed software can be installed, so there will be no way around the DRM. The trusted path from media to screen will be enforced by the hardware, and it will refuse to run if anything has been tampered with.

There is no reason why a user would ever want to have TXT installed on their machine, that cannot already be done with public key based security. The primary difference between traditional public key certificates and TXT, is that in TXT you are not trusted to have access to your own private certificate.

Re:It's a security issue

[Proteus Child]

...and how many people in the security community started out in the hacker community and took great pains to conceal their real names back then? More to the point, how many people in the security community go to great lengths to dissociate their all-grown-up-now professional lives from their days in the hacker scene because it would call unfavorable attention upon their employers, plus put certain of their expensive certifications in jeopardy?

Some people spend years hacking around in their basements and don't feel a need to tell anyone about their work. Others "suddenly appear" because they finally feel like publishing something, the work they publish is brilliant, and thus they gain respect for it.