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.
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.
#fuckbeta #iamslashdot #dicemustdie
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.
End anonymous moderation and posting on
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.
Impersonating Tycho from Penny Arcade since before there was a PA.
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.