Intel Patches Flaws In Trusted Execution Tech 84
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.
Re: (Score:2)
First Word macro viruses, then PDF, and now... (Score:1, Funny)
oh my gawd! Now I can't even use plain TXT documents!! oh wait... nevermind...
Re: (Score:2)
TPMs and related tech (Score:5, Informative)
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: (Score:2)
> If I have access to the hardware, you're screwed
Or more precisely; If Joanna has access to the hardware they are screwed. :-)
Finding and exploiting these flaws is not a widely held skill. Unfortunately for the ones (futilely)* attempting to secure these things, all it takes is for *one* smart and enterprising person to crack it, and then the jig is up.
* And given that it is inevitable for the hardware to get into the hands of Joanna and other likewise bright and curious people, it *is* both a futile an
None of the above (Score:5, Informative)
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 [invisiblethings.org] - she is young and rather attractive.
Re: (Score:1)
Re: (Score:2)
Err...why does any of that matter? I fail to see the issue here, she's a very smart and quite attractive woman.
Re: (Score:1)
It doesn't matter.
I found it interesting the first time I stumbled upon it, so I reposted it here, is all.
Re: (Score:2, Insightful)
Some people spend years hacking around in their basements and
Re: (Score:2)
Hey, be nice, she's a lady.
Re: (Score:2)
Exactly. It's the same problem as with DRM and audio/video - your software can kick ass, but all it takes is one person to break it and everybody has a copy.
Re: (Score:1)
By the way, I don't live under the fridge, you insensitive dyke! X_X
True dat. I am insensitive when it comes to the special needs population of slashdot...
Re:WTF are you doing? (Score:5, Funny)
Re:TPMs and related tech (Score:5, Interesting)
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: (Score:2)
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
Cost? :P
That might just be a factor in security being tacked on as an afterthought. Since people are incredibly shortsighted about everything, the cost here and now is what matters.
So if eating healthy might keep me alive 40 years longer... screw it, cheeseburger! I'll die happy at 65!
And if I have a chance to reduce pollution created at a power plant, so people have reduced medical costs and no environmental cleanup is needed later... screw it, money! $$$
And if face the possibility of getting a girl pregna
Re: (Score:2)
Cost? :P
True -- at first glance there are serious challenges to building a hardware security primitive. But if a cheap device was ever created, it would be a very, very bad day. Control over all the hardware would be in the hands of the key-holders alone...
Re: (Score:2)
The only way I can see hardware security reaching true theoretical unbreakability is if we get to the level where the uncertainty principle prevents observing the hardware in action, but I'm not sure if it will be feasible to have the hardware even run reliably under those conditions.
You can certainly make the hardware hard to crack, but ultimately it is physical in nature and it can be taken apart physically. It is almost impossible to make it theoretically secure, although in practice you can do pretty w
Re: (Score:2)
The only way I can see hardware security reaching true theoretical unbreakability is if we get to the level where the uncertainty principle prevents observing the hardware in action, but I'm not sure if it will be feasible to have the hardware even run reliably under those conditions.
Well, this idea is pretty much the basis for quantum cryptography: if anyone observes the transmission, it gets corrupted. So it's evidently possible for some things.
Re: (Score:2)
Absolutely, and I had this in mind. However, right now quantum cryptography only protects the transmission, not the end-nodes. You'd need a computer where every byte of data in transit, in processing, or in memory associated with the authentication mechanism is protected all the time.
Even that won't really protect you completely since you can do a MITM at any time. The processing circuitry presumably needs to read the data to do work on it. So, you can remove the existing circuitry and replace it with c
Re: (Score:3, Insightful)
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 passwo
Re: (Score:2)
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.
What you're missing is the other application of truly secure hardware -- absolutely, totally, brutally locked down DRM mechanisms. To massive IP companies, it's probably worth it to pour a few hundred million into figuring out how to cheaply build a
Re: (Score:2)
Hopefully it'll never come to that. Don't forget, every DRM doodad added to software and hardware hurts their respective makers. Part of the giant black eye that Microsoft took over Vista was because of the reliability implications of all of that "trusted path" and "degradation" garbage. Stuff that doesn't do spit to increase the value of the hardware or software to the customer, and it boosts the costs to the developer/manufacturer without any extra revenue, it just placates the MafiAA. So at this poin
Re: (Score:1)
Hardware can be made secure by making it tamper-resistant. Cryptographic ICs can be rigged to self-destruct when somebody opens the package.
Sometimes you don't even need to expose the silicon to mess with the guts of a chip. You can still connect to the pins or solder pads of an IC and monitor signals passively, or introduce overvoltage/undervoltage/weird signal patterns from outside.
Re: (Score:2)
It was true fifty years ago, and it's still true today: If I have access to the hardware, you're screwed.
But will that still be the case when computers consist of isolated atoms embedded in a diamond lattice? The equipment required for hacking will certainly be different.
Re: (Score:2)
The tools change yes, but you will still have inputs and outputs. as long as you have those hacks are still possible. just a lot smaller.
Re: (Score:2)
It's funny isn't it... It took 10 years for someone to read the boot rom of the Super Game Boy (and similar time for the Game Boy?), but the XBox was hacked in a similar fashion much faster.
I think if it takes 10 years for someone to break it then it could be deemed secure... the trouble with that is that it's only true retrospectively :)
Re: (Score:2)
Please note that Unix was designed from the ground up to be secure, and there've been exploits, root kits and vulnerabilities in it over the years. Not many, compared to some other systems, but enough to show that making a secure system and keeping it that way is a non-trivial exercise.
Re: (Score:2, Informative)
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: (Score:1, Funny)
NT was designed from the ground up to be secure
Just Microsoft botched the implemementation of that
Chipset patch? (Score:2, Funny)
Do I have to weld it on or something?
Comment removed (Score:4, Funny)
Re: (Score:2)
No. You'll be fine and should go for it :)
You can always press undo later...
Readme.TXT (Score:5, Insightful)
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 (Score:5, Insightful)
"Hey Jim, you know what computing needs? more ambiguous acronyms. That would be just grand."
Re: (Score:2)
Re: (Score:1, Interesting)
What about not executing what isent set +x.. and save by default new file as -x.
Oh that right, it already the case except on flawed OS.
Re: (Score:1, Troll)
Re: (Score:1)
I don't agree that this will solve anything. People who are likely to double click on cute_cat.jpg.exe are just as likely to not know the difference between song.mp3.exe and songmp3.exe.
"it says mp3 right there in the file name"
Re: (Score:3, Informative)
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 use
Re: (Score:2)
And oh, dear me, that resource/fork mess was unstable. They inevitably fell out of sync during hardware issues or during software problems, and completely ruined MacOS filesystems and components. Re-implementing that mess would be like bringing back punch cards. Sure, they have some advantages in stability, but the mostly useless overhead of handling them is unacceptable.
Re: (Score:2)
Actually, the most common problem with standard HFS drives had nothing to do with file forks. There was no backup of the structures necessary for the integrity of the filesystem in standard HFS. With the not at all uncommon hard lock ups and reboots in MacOS 7.5* to 8.1 one structure is bound to get corrupted, especially if the caching policy for the write cache on the hard drive is set to write-back.
At any rate, the type of problems present in standard HFS are no longer a factor, backup superblocks and b
Re: (Score:1)
So all in all (Score:1)
Not Trusting The User (Score:5, Informative)
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: (Score:2)
I had been wondering about that. It seemed to me that it describes a system in which you don't have control of your system and couldn't poke around in the process to find out what it was doing.
I'll stick with the broken version, thanks.
so how will asimov's laws be implemented? (Score:1)
won't the 3 laws of robotics require impregnable systems? even, especially, to users?
Re: (Score:1)
But I agree that there is probably is very little need for a typical user to be running TXT on their machine; I definitely don't trust MS/MPAA/etc not to abuse the technology
Re: (Score:2)
My impression is that with TPM and TrouSerS, *I* can put the master key into the TPM, assuming nobody else has gotten there, first.
Come to think of it, you've just described a new LiveCD. This would be a LiveCD that should be the very first thing you boot in your new PC, especially before you boot the supplied (probably Windows) OS. Boot the LiveCD, plug in a USB flash memory, and it will set up the TPM/TXT for you, putting the necessary root cert stuff on the flash memory for your later use.
Given the nat
Re: (Score:2)
Nope. All TPMs are shipped with a key already in them, though you can load your own key in addition to the shipped one.
Re: (Score:2)
Where does that key come from? Is it unique for every TPM, like a network card MAC?
Never mind, a few moments with google... It looks like the "Endorsement key" is chip-unique, in 2 parts, and you can only get the public part, and ask the TPM to sign/encrypt with the private part. It's not at all clear to me that ANYONE knows the private part. In particular, if the TPM has its key manufactured in, it would be a royal pain in the neck to manage the data, correlating private and public keys. (Where "royal
Re: (Score:2)
It looks like the "Endorsement key" is chip-unique, in 2 parts, and you can only get the public part, and ask the TPM to sign/encrypt with the private part. It's not at all clear to me that ANYONE knows the private part.
Nope, no-one should know the private part; in fact, according to some information, it's generated on-chip and never leaves the TPM. The whole point is that the endorsement key can be used to verify that the TPM is in fact a genuine one, and not a piece of software emulating a TPM. In turn, the TPM can then verify that your computer is running an authorized operating system (remote attestation).
This is a less-than-ideal approach if you - as an end-user - just want to verify a particular TPM you control signe
Re: (Score:2)
Let's leave the MafiAA out of this for a moment. Sometimes it seems to me that most users really can't be trusted with their computers.
Click this link!!!
Open thie attachment!!!
The littany goes on and on, and no matter how many times they're warned, they still click that link and open that attachment.
For that matter, none of us fully trusts ourselves, in all circumstances. After all, we all say, "Never do normal operations as root, only use root as necessary." That's been considered the first line of secu
Re: (Score:2)
I missed that line. Is it true that TXT doesn't let you control your own root cert?
I have a Thinkpad. I keep the TPM stuff in my kernel config, and I've built Trousers. Actually doing something with it has been on my ToDo list for years now. Nor have I tried Trusted Grub.
Re: (Score:2)
The wording is "are capable of", and it emphasizes the importance to me of siezing control of your own TPM. Elsewhere on this thread I suggested the creation of a LiveCD that would (first!) access the TPM, giving the owner the private key on a USB flash device. It would be of utmost importance to boot this disk FIRST, before ever booting the preinstalled OS.
I seriously doubt that manufacturing cost constraints would permit injecting private keys - I would expect such injection to take place upon first boo
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Only signed software can be installed, so there will be no way around the DRM.
Can the computer industry really go along with this? There are bajillions of software packages that have never been signed.
BIOS Updates? (Score:1)
/me wonders when we can expect updated BIOS from Asus and others?
Re: (Score:1)
Upgrade... (Score:2)
Sounds like Intel needs to move to the Systematic Hardware Integrated Trust standard...
It's Funny Until ... (Score:2)
It's Funny Until ...
Subversionhack:
http://subversionhack.livejournal.com/ [livejournal.com]
https://tagmeme.com/subhack/a/index.html [tagmeme.com]
http://slashdot.org/comments.pl?sid=1135787&cid=26950187 [slashdot.org]