Slashdot Log In
Researchers Hack Intel's VPro
Posted by
kdawson
on Tue Jan 06, 2009 05:18 PM
from the joy-of-breaking-the-unbreakable dept.
from the joy-of-breaking-the-unbreakable dept.
snydeq writes "Security researchers from Invisible Things Lab have created software that can 'compromise the integrity' of software loaded using Intel's vPro Trusted Execution Technology, which is supposed to help protect software from being seen or tampered with by other programs on the machine. The researchers say they have created a two-stage attack, with the first stage exploiting a bug in Intel's system software. The second stage relies on a design flaw in the TXT technology itself (PDF). The researchers plan to give more details on their work at the Black Hat DC security conference next month."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
TXT? PDF? Wha? (Score:5, Funny)
So we need to read a PDF to read about flaws in TXT?
What do you mean it's not about plain text files?
Re: (Score:2)
I can't you're joking. Whoosh if you are.
If not: TXT: Trusted Execution Technology
Re: (Score:2, Insightful)
My mistake.
1. can't tell if you're joking.
2. Execution, not Execution.
Re: (Score:2, Funny)
I can't you're joking. Whoosh if you are.
If not: TXT: Trusted Execution Technology
Guillotin?
Re: (Score:2)
Yes, I was joking. And no, I did not know TXT also meant "Trusted Execution Technology". It's not my fault if someone was dumb enough to choose a 3-letter acronym that's been used for decades in the computers domain.
Re: (Score:2)
Well of course, if they used a TXT file you might get hacked!
Design flaw in the TXT technology (Score:2, Funny)
Apparently, loading a pdf into wordpad causes an overflow that allows arbitrary code to run as administrator.
Re: (Score:2)
And nobody would ever do that, would they?
Re:Design flaw in the TXT technology (Score:5, Funny)
Parent
Wii Homebrew Channel (Score:5, Funny)
Re:Wii Homebrew Channel (Score:5, Insightful)
Let me correct that for you:
The Wii has perfect ^H^H^H^H^H^H an encryption and signing on hardware-assisting firmware and system software that can't be ^H^H^H^H^H^H hasn't been compromised.
Parent
Re: (Score:3, Interesting)
On the same note, has anyone cracked the xbox 360 hardware security? The only thing i see so far is that XFPS device which uses a "man in the middle" attack to hijack the connection between a controller and the console itself.
Re: (Score:2)
Re: (Score:3, Informative)
Yes. Google '360 timing attack'. All keys can be retrieved, at which point you can disable/bypass the encryption at any stage after the very first hardware-embedded loader signature checks.
Re:Wii Homebrew Channel (Score:5, Informative)
Someone's been living under a rock since December 2007.
I'll just point you to the recent 25th Chaos Community Congress Console Hacking talk (slides [marcansoft.com], video [tu-ilmenau.de]) which neatly summarizes a year of hacking and how much of a horrible failure Nintendo's security has been.
Spoiler: their signatures used to have 8-bit security. Literally.
We've had lots [hackmii.com] of [youtube.com] fun [wiibrew.org].
Parent
Re: (Score:2)
109-bit ECC keys give about 2^54 security
232-bit ECC keys give about 2^116 security
It's only a difference of 2^62!
Re: (Score:2)
Apparently someone missed the sarcasm tags here.
This is NOT a Troll.
I would mod, but I figured since nobody'd posted this I'll do that instead
This can't be possible! (Score:5, Funny)
Quick! (Score:4, Funny)
Quick, somebody arrest these scoundrels! How dare they show flaws in technology! The next thing you know, fraudsters and pornographers will be taking advantage of this. THINK OF THE CHILDREN!!! THINK OF 9-11!!!
Thank you! (Score:5, Insightful)
RMS calls this "treacherous computing", and I have to agree with him. This is a good development as it demonstrates quite nicely that DRM (which is probably the #1 use of VPro et al) in simply not possible. Thanks, ITL, for showing this as folly!
Re:Thank you! (Score:5, Interesting)
That is completely different that what DRM for multimedia is. For multimedia, they want you to be able to view the content without being able to copy them, which is fairly ridiculous.
For TPM (or whatever the marketing acronym is now), they're just using hardware to ensure that only signed binaries are executed. There's valid reasons to want this as a user. For instance, sign the kernel. On first run, error out saying the app isn't signed and ask you to sign it yourself (or for things like linux distros, the binaries are signed by the distro or repo). Thus viral infections by modifying binaries & rootkits become much more difficult (e.g. theoretically a system that starts out non-compromised cannot become so by modifying existing programs and would need you to actively sign compromised apps before they start).
Here's the overlap and the reason it's bad: from what I understand, the signing authority must be the TPM chip maker. Thus you're relying on potentially someone you don't trust to perform the signing, instead of being able to chose whome to trust. Very likely, it'll be used to strip the user of the capability to do what they want. For example, wanna play a DVD? Only friendly, region-obeying, DVD playing software is allowed. Wanna play music? Only software that honors DRM restrictions allowed.
Parent
Flaws? Or by Design? (Score:2)
Re:Thank you! (Score:4, Interesting)
Bullshit, not a single person working on TPM at Intel thinks it will ever work for DRM. I say this as someone who as talked with several of the security architects and TCG liaisons (in a non-professional setting).
TPM does close to nothing to prevent local attacks. What it is meant for is to prevent remote attackers from digging too deep by providing a safe place to store keys.
It is used to sign code. What Joanna did is what she always does, she found a fun way to get arbitrary code to execute when only signed code is supposed to be able to.
Parent
Re:Thank you! (Score:5, Insightful)
Keyword, at Intel. TC is the work of a large committee, with many companies. If you read the specs the conflicting goals are obvious. Simple question - is the TPM meant to resist hardware attacks or not? Sometimes it is, sometimes it isn't. It's not very good at this currently, you could beat 1.1 TPMs with a piece of wire (literally), but Intel are moving them inside the south bridge, where hardware attacks will be much harder.
In theory at least TC can be used to implement better DRM, because it makes it harder for people to debug the implementation. But there are still many unimplemented features needed to make this work, eg, trusted I/O, and no real roadmap to implement them. And even when done, it'll be years before the technology is widespread, and it's so complicated I'm sure Joanna and friends will be able to find many more problems with it.
The real promise of TC is a way out of the malware quagmire. Being able to run a web browser and know - for sure - that it's not been compromised by a password sniffer or the like, well, that's a useful thing and that's what TXT lets you do (when complete). A remote voting app that can prove to the server that it's a real human casting the vote and not a bot? A very useful thing, perhaps even a necessary precondition for digital democracy. TC can make this happen. DRM? Well if you want a crappy inferior very complex form of DRM then sure, go ahead, but it'll be less secure and more expensive than the equivalent implemented in controlled hardware like the PS3, Xbox360, mobile phones etc ...
Parent
Re: (Score:3, Insightful)
Being able to run a web browser and know - for sure - that it's not been compromised by a password sniffer or the like, well, that's a useful thing and that's what TXT lets you do (when complete).
No it won't. If the said browser behaves erroneously on a particularly crafted web page the web page creator might be able (depending on the error) to take full control of the machine, e.g. by injecting remotely controllable ("telnet") Javascript applet.
For voting the TC cannot *prove* anything - again a simple overflow (either buffer or integer or ...) bug can make the bot look exactly like human to the TC. TC can "prove" provided there are no bugs. Which is lame.
Re:Thank you! (Score:4, Insightful)
Bullshit, not a single person working on TPM at Intel thinks it will ever work for DRM.
Funny, as it's the first listed possible application [wikipedia.org] on Wikipedia. How could TPM possibly not be used for DRM? All the ingredients are there. From the same article:
Isn't that almost the very definition of DRM?
Parent
Re:Thank you! (Score:4, Insightful)
Excuse me... let me phrase that correctly: "Bullshit, not a single person working on TPM at Intel will admit that was designed for DRM."
The entire reason for the project (started back in the late 90s) was DRM - or, as one Intel engineer at a talk I attended put it - "making a system secure against its owner". Only later they decided, after users started to realise just what TXT really means for them (total control by the likes of Microsoft), that they would smother the whole "for DRM" thing and flatly refuse to ever discuss it. Instead they always emphasise the "security" aspects instead. Only morons are fooled - hello there.
Anyone who thinks that Intel is not about DRM is an idiot. Intel is *THE* DRM kingpin (HDCP etc etc).
Parent
Re: (Score:2)
Not to mention no easy local recovery. Try replacing a burned out motherboard on a server with bit locker. No recovery disk, no data:P
Re:Thank you! (Score:5, Insightful)
Orly?
What a load of crap. At best you are merely naive.
I am a programmer, and in particular I have studied the Trusted Platform Technical Specification documentation. All 332 pages of dense technicaleese. There is one particular page I would like to cite. In the TCPA Main TCG Architecture v1_1b.pdf on page 277 the documentation comes right out and announces the fact it is designed to be secure against "rogue Owners".
You are either mistaken, or you're full of crap. The chip is in fact designed to lock the computer against the owner. Yes, locks that are designed to protect the computer against it's owner will also prevent outside attackers from doing things that the owner himself is forbidden to do. However that is incidental. A hostile Trusted Computing system trying to lock computers against their owners is fundamentally different than a system designed to secure computers for the owner.
If you really do believe that this is solely intended for the benefit of the owner, perhaps you could answer some questions for me.
Why the absolute refusal to implement the EFF's Owner Override proposal? It would give the owner full control of his own computer while still securing against remote attacks. You could even secure against local attackers (other than the owner) by placing adding some sort of Owner Authentication element to the Override system.
Or how about my proposal? I merely want a printed copy of the master key to my own computer. I merely want the option to buy a computer that comes with a printed copy of my master key. (Technical note: I am referring to the PrivEK key, and having the option to export the RSK key encrypted to the PrivEK would be beneficial for ease and security reasons.) Go ahead, explain to why I am absolutely forbidden to know the master key to my own computer. Go ahead and explain why they absolutely refuse to PERMIT anyone to manufacture any compatible Trust Chip that permits the owner to know their own master key.
And best of all, explain to me all of the documented systems and plans to REVOKE and (for all practical purposes) brick any chip if they ever detect that you have learned the master key locked inside you computer, if you ever learn the master key to control your own computer, if they ever detect that you have the power and control to override any DRM system based on the chip.
And don't even try the line about how this revocation system is "not part of the chip itself". The chip was explicitly designed to secure the computer against the owner, the chip was explicitly designed to to support that revocation system, and the chip's technical documentation and design specification explicitly mention this revocation system.
The design specs endlessly list all of the things that the owner MUST be forbidden to be able to do, all of the things the owner MUST be forbidden to know, the specification even has a section that mandates that any owner's data under "non-migable keys" MUST be effectively impossible to back up and MUST be irretrievably lost if the chip ever dies.
And on and on and on. Yes, the chip was explicitly designed to consider the owner to be the enemy. The chip is explicitly designed to be secure against "attacks" by the owner. Yes, the current generation of chips are relatively vulnerable to physical attack - by the owner or by a hostile attacker. However it is fundamentally designed to lock against the owner, there is a supplemental specification on how to increase the physical security against the owner and how to certify hardware as possessing stronger anti-owner physical security, and there is mention in the CHIP speck itself and in supplemental specifications on how to revoke and lock-out any chip where an owner does manage to gain local override control over his own computer.
Yes, there are some people working on Trusted Computing with the intent of securing your computer for you, of protecting you against remote attackers. However that does not change the fact tha
Parent
Re: (Score:2)
Using the TPM, true practical disk encryption may finally become reality.
As long as your definition of "practical" includes "unrecoverable", as in what your data will be if your motherboard fails.
Re: (Score:3, Interesting)
Bingo! We have a winner! You would have to be nuts to use TPM when something as mundane as a mobo failure can cause all your data to go poof. But I have a more fundamental problem with it. If I buy a car you better hand me the damned keys, I buy a house, a lockbox, same thing. There ain't no way in hell I'm shelling out good money on a PC that has a lock that they won't give me the damned keys to.
I avoid software that expects us to pay full price for a rental, and TPM is the same thing. Without the keys
Another repeat: the unlockable lock (Score:5, Insightful)
Never a lock has been created that can't be broken.
Any time you see "unbreakable", "unsinkable" or similar claims, call your bookie: they will. The question is when, not if.
Re: (Score:2)
If it can't even be opened with a key, you can't use a lock pick, can you?
Re: (Score:3, Funny)
The one I keep in my truck.
http://www.amazon.com/Bare-Tool-Cordless-Reciprocating-Contractors-Special/dp/B000VEUVZE [amazon.com]
Re: (Score:2, Insightful)
risking to be modded troll, i would like to say sure there is an unbreakable lock. An unbreakable lock is a lock that noone cares enough to break.
Re: (Score:2)
Then why can't I rip my SACDs yet?
Because in an age where 128Kbps MP3s are the norm, no one really cared about SACD or DVD-Audio to bother.
Re: (Score:3, Interesting)
I've been trying to get my friends (the more technically-oriented ones, anyway) to rip to FLACs to keep on their primary machine, and to use my program (see my sig) to convert to decent-quality Oggs or MP3s for portable use.
I convert to Oggs mainly because MP3s aren't designed for gapless playback, and they work with Rockbox. "-q 6" gives VBR at around 192kbps -- more than enough for a portable player going over a
Re: (Score:2)
If you use LAME to encode your MP3s and play them on a supporting player, you can get gapless. Foobar2000 and Rockbox, at least, support LAME's gapless playback headers.
Re: (Score:3, Funny)
Just use the analog hole, SACDs may be cracked eventually if somebody else starts using them though.
Bug in 'system software' (Score:2, Interesting)
Invisible Things Labs is J. Rutkowska (Blue Pill) (Score:5, Informative)
Wrong Wrong Wrong (Score:5, Insightful)
vPro is mostly about AMT OOB management which is secure and is in it's 5th generation. TXT is relatively new component which is implemented virtually nowhere yet and has virtually nothing to do with the AMT functionality that has been and is being implemented hundreds of sites. AMT management is 97% of what vPro really is and is what the industry system OEMs generally mean when they say vPro. TXT is a future technology waiting for ISV enablement whereas core AMT/vPro is real and here now. Saying that because TXT may be compromised AND suggesting that the primary, working part of vPro is insecure is outrageously misleading.
Re: (Score:2)
Re: (Score:2)
vPro is mostly about AMT OOB management which is secure and is in it's 5th generation. TXT is relatively new component which is implemented virtually nowhere yet and has virtually nothing to do with the AMT functionality that has been and is being implemented hundreds of sites. AMT management is 97% of what vPro really is and is what the industry system OEMs generally mean when they say vPro. TXT is a future technology waiting for ISV enablement whereas core AMT/vPro is real and here now. Saying that because TXT may be compromised AND suggesting that the primary, working part of vPro is insecure is outrageously misleading.
Thanks for the post. This is just what I wanted to say. My team has specified vPro PCs to replace the current PCs specifically for the management features. If you manage a large PC environment it's worth taking a look at.
Blue Pill (Score:2)
Re: (Score:2)
Re:TXT execution technology (Score:5, Funny)
Parent
Re: (Score:2, Funny)
Re: (Score:2)
Isn't there an Emacs Key combo that does that?
Re: (Score:2)
Real programmers code in binary [krytosvirus.com]