Some months ago there were some press announcements re attacks on TXT by Joanna Rutkowska's group at Invisible Things Lab (ITL). I believe it had to do with SMM and the semi-mythical SMM Transfer Monitor supported by TXT.
Recently there was a new TXT flaw found by the same group. Details of the attack, and updated SINIT modules from Intel, were released yesterday. Somewhat ironically, the SINIT bug relates to a problem area many of us have run into in unsuccessfully trying to get various machines to go into TXT mode, namely the DMAR table in memory which describes devices and their memory access translations. This table is prepared by BIOS, but SINIT doesn't trust it. It goes over it with a fine tooth comb, checking it against the actual hardware devices which SINIT finds to exist, and then when SINIT is satisfied, it copies the table into secure memory for use by tboot. I and others have had problems where SINIT doesn't like something about the table and refuses to launch, leaving us scratching our heads as to what is wrong. ITL did not bother with head scratching, they just disassembled the SINIT code to see what it was doing. (This is because they were looking for attacks rather than trying to help befuddled would-be tboot users, but I can't help thinking that their skills would be useful in our debugging efforts.) They discovered a bug, as I said: a certain device register is 64 bits but SINIT only read the lower 32 bits and used that as an address. Oops, an easy mistake to make; I have done much the same but that software was not security sensitive. ITL wrote something into the high 32 bits before launching TXT and as a result the device table is not where SINIT thinks it is, hence SINIT gets fooled, and as they say, 0wned. Specifically SINIT doesn't find out about one of the DMA units and doesn't set it up with VT-d protections, allowing it to later be made to spray all over memory right on top of the supposedly protected region. I suppose I should remind readers of my call for Intel to open-source this security critical code in the hopes that our many eyes may find bugs without relying on embarrassing public press releases saying that TXT is broken. Invisible Things blog posting with link to paper: http://theinvisiblethings.blogspot.com/2009/12/another-txt-attack.html Intel security advisory: http://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00021&languageid=en-fr Fresh new SINIT modules available from sourceforge: http://sourceforge.net/projects/tboot/files/ So where is the CRL so we know not to trust attestations from broken SINITs? Or something like OCSP with a server run by Intel that we can query to see which SINITs are good and which are bad? Intel is going to be in trouble if anyone actually starts to use this technology, with their current lack of attention to these kinds of details! Hal Finney ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
