tboot-devel

[tboot-devel] Attack on tboot/TXT to be revealed

[Hal F. <hal...@gm...>]

Ran across this blog posting reporting an attack on the security of
tboot and/or TXT:

http://theinvisiblethings.blogspot.com/2009/01/attacking-intel-trusted-execution.html

see also:

http://invisiblethingslab.com/press/itl-press-2009-01.pdf

>From the documents:

"Our attack comprises two stages. The first stage requires an
implementation flaw in a specific system software. The second stage of
the attack is possible thanks to a certain design decision made in the
current TXT release.

"While evaluating the effectiveness of the Intel(R) TXT technology, as
part of a work done for a customer, we have identified several
implementation flaws in the Intel's system software, which allowed to
conduct the above mentioned stage-one attack. We have provided Intel
with extensive description of the flaws in December 2008, and Intel is
currently working on fixing those vulnerabilities.

"We have also been in touch with Intel about the possibility of
conducting the second-stage attack since November 2008. In December,
after providing Intel with the details about the first-stage attack,
Intel promised to release, in the coming weeks, an updated TXT
specification for developers that would explain how to design their
TXT-based loaders in such a way that they are immune to our attack.
Intel claims the current Intel(R) TXT release does contain the basic
building blocks that could be used to prevent our second-stage attack
and the release of the additional specification would make it feasible
in practice."

More details are to be announced at the Black Hat conference in
February, in Washington DC.

It will be interesting to learn more about this attack scenario over
the next few weeks. Hopefully Intel will be able to release
information to help assure developers that the security potential of
TXT is fully realized. It has sometimes been unclear to me whether
tboot claims to provide full TXT security or is still considered a
work in progress, with known weaknesses which are intended to be
addressed in future versions.

Hal Finney

Re: [tboot-devel] Attack on tboot/TXT to be revealed

[Jonathan M. M. <jon...@cm...>]

I wonder if this is related to the TPM driver bug recently posted to the 
tpmdd-devel list:

*** snip ***
Please correct me if I am wrong, but this bug DOES mean we are basically 
doing:

if (random memory contents)
   (random memory contents)(foo);

at suspend and resume, isn't it?
*** snip ***

-Jon



Hal Finney wrote:
> Ran across this blog posting reporting an attack on the security of
> tboot and/or TXT:
>
> http://theinvisiblethings.blogspot.com/2009/01/attacking-intel-trusted-execution.html
>
> see also:
>
> http://invisiblethingslab.com/press/itl-press-2009-01.pdf
>
> >From the documents:
>
> "Our attack comprises two stages. The first stage requires an
> implementation flaw in a specific system software. The second stage of
> the attack is possible thanks to a certain design decision made in the
> current TXT release.
>
> "While evaluating the effectiveness of the Intel(R) TXT technology, as
> part of a work done for a customer, we have identified several
> implementation flaws in the Intel's system software, which allowed to
> conduct the above mentioned stage-one attack. We have provided Intel
> with extensive description of the flaws in December 2008, and Intel is
> currently working on fixing those vulnerabilities.
>
> "We have also been in touch with Intel about the possibility of
> conducting the second-stage attack since November 2008. In December,
> after providing Intel with the details about the first-stage attack,
> Intel promised to release, in the coming weeks, an updated TXT
> specification for developers that would explain how to design their
> TXT-based loaders in such a way that they are immune to our attack.
> Intel claims the current Intel(R) TXT release does contain the basic
> building blocks that could be used to prevent our second-stage attack
> and the release of the additional specification would make it feasible
> in practice."
>
> More details are to be announced at the Black Hat conference in
> February, in Washington DC.
>
> It will be interesting to learn more about this attack scenario over
> the next few weeks. Hopefully Intel will be able to release
> information to help assure developers that the security potential of
> TXT is fully realized. It has sometimes been unclear to me whether
> tboot claims to provide full TXT security or is still considered a
> work in progress, with known weaknesses which are intended to be
> addressed in future versions.
>
> Hal Finney
>
> ------------------------------------------------------------------------------
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>   

Re: [tboot-devel] Attack on tboot/TXT to be revealed

[Hal F. <hal...@gm...>]

There is one aspect of tboot security which I always wondered about.
Maybe someone could reassure me that it is OK.

Shouldn't the MLE check to see that the page tables are/were set up
correctly? It seems that TXT envisions that the MLE will turn on
paging, but I don't think tboot does so, it stays in physical memory
mode. However, TXT measures the MLE via the page tables. My concern is
whether a malicious tboot could move pages 2-n of the MLE up one page,
insert malicious code in the 2nd physical page, and set up the page
tables to skip the page with the malicious code. Then TXT, following
the page tables, would measure the same hash value as unmodified
tboot, but when the code executed and crossed over from the 1st page
into the 2nd page, it would start executing malicious code.

To prevent this, the MLE should check, within page 1, that the page
table used for measurement matches what it was supposed to be. I'm not
certain, but I don't think there is such a check in tboot. Is this an
issue?

Hal Finney

Re: [tboot-devel] Attack on tboot/TXT to be revealed

[Cihula, J. <jos...@in...>]

> From: Hal Finney [mailto:hal...@gm...]
> Sent: Tuesday, January 06, 2009 7:26 PM
>
> There is one aspect of tboot security which I always wondered about.
> Maybe someone could reassure me that it is OK.
>
> Shouldn't the MLE check to see that the page tables are/were set up
> correctly? It seems that TXT envisions that the MLE will turn on
> paging, but I don't think tboot does so, it stays in physical memory
> mode. However, TXT measures the MLE via the page tables. My concern is
> whether a malicious tboot could move pages 2-n of the MLE up one page,
> insert malicious code in the 2nd physical page, and set up the page
> tables to skip the page with the malicious code. Then TXT, following
> the page tables, would measure the same hash value as unmodified
> tboot, but when the code executed and crossed over from the 1st page
> into the 2nd page, it would start executing malicious code.
>
> To prevent this, the MLE should check, within page 1, that the page
> table used for measurement matches what it was supposed to be. I'm not
> certain, but I don't think there is such a check in tboot. Is this an
> issue?

This has been on my todo list for a while now but I haven't gotten to it yet (it *is* covered in the MLE Developers Manual, however).  Now that I just finished a few patches (and one more to come that requires Xen support), I should be able to knock this out pretty soon.

Joe

Re: [tboot-devel] Attack on tboot/TXT to be revealed

[Hal F. <hal...@gm...>]

>> From: Hal Finney [mailto:hal...@gm...]
>> Sent: Tuesday, January 06, 2009 7:26 PM
>>
>> There is one aspect of tboot security which I always wondered about.
>> Maybe someone could reassure me that it is OK.
>>
>> Shouldn't the MLE check to see that the page tables are/were set up
>> correctly?

On Tue, Jan 6, 2009 at 11:25 PM, Cihula, Joseph <jos...@in...> wrote:
>
> This has been on my todo list for a while now but I haven't gotten to it yet (it *is* covered in the MLE Developers Manual, however).  Now that I just finished a few patches (and one more to come that requires Xen support), I should be able to knock this out pretty soon.

I would like to see a document which lists known security flaws like
this in tboot. It might help to reduce claims that "Intel TXT is
broken" and the like. Do you know of other security loopholes which
are planned for closure in future versions?

Hal

Re: [tboot-devel] Attack on tboot/TXT to be revealed

[Cihula, J. <jos...@in...>]

> From: Hal Finney [mailto:hal...@gm...]
> Sent: Wednesday, January 07, 2009 2:49 PM
>
> >> From: Hal Finney [mailto:hal...@gm...]
> >> Sent: Tuesday, January 06, 2009 7:26 PM
> >>
> >> There is one aspect of tboot security which I always wondered about.
> >> Maybe someone could reassure me that it is OK.
> >>
> >> Shouldn't the MLE check to see that the page tables are/were set up
> >> correctly?
>
> On Tue, Jan 6, 2009 at 11:25 PM, Cihula, Joseph <jos...@in...> wrote:
> >
> > This has been on my todo list for a while now but I haven't gotten to it yet (it *is*
> covered in the MLE Developers Manual, however).  Now that I just finished a few patches (and
> one more to come that requires Xen support), I should be able to knock this out pretty soon.
>
> I would like to see a document which lists known security flaws like
> this in tboot. It might help to reduce claims that "Intel TXT is
> broken" and the like. Do you know of other security loopholes which
> are planned for closure in future versions?

I'll work on creating a TODO list for tboot, which will include the implications/impact of the items and also will include functional tasks.

These are the TODO items that I know of that have security implications:
1.  Verification of post-launch physical memory layout (see above).  A patch is ready and being reviewed.
2.  VT-d protections extended to all of usable memory.  The current tboot setting for VT-d (PMR) DMA protection is just the tboot address range, which leaves out Xen, dom0, etc. as well as where they are relocated to before Xen enables VT-d DMA remapping.  A patch is ready and being reviewed.
3.  S3 memory integrity protection.  The non-tboot TCB (and possibly more) needs to have its integrity measured before entering S3 and verified on resume.  For Xen, this would be the hypervisor and that would be responsible for doing this for domains (including dom0).  A patch is ready and being reviewed.
4.  Validation of Sx addresses.  We are adding GAS (generic address structure) support to tboot's Sx code.  GAS allows for non-port -based Sx triggering (i.e. memory writes).  This allows for the possibility that malicious ACPI code (or tampered with before tboot) could reference addresses within Xen or tboot and cause overwrites when a sleep state is entered.  So the addresses should be checked against tboot/Xen/domain addr ranges before being used.  This is part of the GAS support patch, which is ready and being reviewed.
5.  Run tboot code through a static analysis checker.
6.  Perform a thorough tboot code and design review on latest code.

There are also some things that are not directly related to tboot, but are really only relevant if tboot is being used:
1.  Review all Xen code for pre-launch dependencies.  This would be things like the GAS issue mentioned above, BIOS calls (which should all be disabled when invoked by tboot), etc.
2.  Ensure Xen fails secure.  This would include things like the 'iommu=required' and 'ats' command line parameters that we had added.

Joe