Anti Evil Maid for grub2,tboot,fc18

[Olivier Médoc]

Hello,

I started to test antievilmaid and got some success here, meaning it boots, fill some PCRs, but I'm not sure that it is usable to really protect against anti evil maid attacks.

First, I attached several patches to make it working with fedora 18, systemd ... I removed the hack to trigger antievilmaid before the system ask for a passphrase because we can do that with systemd. Note that I didn't tested the patches (I just tried to compile it), but the changes applied manually on my system are working.

Also note that the anti-evil-maid systemd service starts only if rd.antievilmaid is set, which means that the generated initrd will not break a standard boot.

Installing tboot is straightforward:

- Install tpm-tools, trousers, tboot

- Start tcsd (systemctl start tcsd)

- download tboot SINIT modules (only for intel because it uses TXT ?):

https://secure-software.intel.com/en-us/protected-download/267276/183305

- add an entry in /boot/grub2/grub.cfg by copying a valid qubes entry and changing the following lines:

# Add vga_delay=10 (10 seconds) for debugging on the following line
multiboot /tboot.gz placeholder logging=vga,memory,serial
module /xen.gz placeholder console=none
module...
module...
module...
# Append this line after the last module. If this line is not there it will boot correctly but it will not set the PCR values 17 to 19
module /i5_i7_DUAL_SINIT_51.BIN

If everything went fine, when you reboot you should have the following PCR values set:

PCR 0-3: BIOS, Option ROMs, Platform Config
PCR 4 : MBR (Grub stage1)
PCR 5-7: OEM-specific, probably safe to skip

Additionnaly, tboot added the following PCR values (depending on the tboot config : DA mapping can be enabled if the following is used on tboot command line: pcr_map=da for pcr_map=da|legacy)

The PCR values added by tboot are the following (the comments comes from my own analysis, extrapoled from TBoot PCR mapping documentation in /usr/share/doc/tboot-1.7.0/README)

# Legacy PCR Tboot mapping
PCR-17 : tboot policy control value, tboot policy (not changed anyway so we don't care ?)
PCR-18 : tboot.gz (lcp_mlehash), grub.conf first module (xen.gz)
PCR-19 : all other modules

# Details / Authorities PCR Mapping (DA)
PCR-17: tboot policycontrol value, tboot policy, first grub.conf modules (xen), all other modules
PCR-18: tboot policycontrol value, tboot policy

It seems to use a legacy mapping by default. I observed changes in the PCR value (by adding vga_delay=10 in the tboot line to read all the tboot details) and it effectivelly change the PCR 19 value.

Now the questions/comments are:

- PCR-8 (grub stage2) and so on until PCR-12 are not set. Is it a risk knowing that tboot fill PCR-18 and PCR-19 with most of the required hashes ?
- I don't use tboot policy mecanism, and I don't set any policy (all hashes related to the policies are set to 0). These policies are apparently used for dynamic boot verification using TXT or something like this. If I remember the antievilmaid terminology, we want the static variant. Is it correct?
- It seems like I need to use this SINIT module downloaded from intel web site. If not, I'm not able to fill PCR-18 and PCR-19. I think it force use of the intel TXT technology somehow. What about non intel processors ? How can I trust this binary module ? What are the risks here ?
- If tboot fill correctly PCR17-to-PCR19, can I seal my secret with PCR0-to-3 and PCR17-to-PCR19 ?

Sorry with all the things that are uncertain. I concentrated on the technical part, and now I have to study more in details the anti-evil-maid concept. Maybe you can help me there :P

Olivier

[Joanna Rutkowska]

On 06/24/13 17:14, Olivier Médoc wrote:
> Hello,
>
> I started to test antievilmaid and got some success here, meaning it
> boots, fill some PCRs, but I'm not sure that it is usable to really
> protect against anti evil maid attacks.
>
> First, I attached several patches to make it working with fedora 18,
> systemd ... I removed the hack to trigger antievilmaid before the system
> ask for a passphrase because we can do that with systemd. Note that I
> didn't tested the patches (I just tried to compile it), but the changes
> applied manually on my system are working.
>
> Also note that the anti-evil-maid systemd service starts only if
> rd.antievilmaid is set, which means that the generated initrd will not
> break a standard boot.
>
> Installing tboot is straightforward:
>
> - Install tpm-tools, trousers, tboot
>
> - Start tcsd (systemctl start tcsd)
>
> - download tboot SINIT modules (only for intel because it uses TXT ?):
>
> https://secure-software.intel.com/en-us/protected-download/267276/183305
>
> - add an entry in /boot/grub2/grub.cfg by copying a valid qubes entry
> and changing the following lines:
>
> # Add vga_delay=10 (10 seconds) for debugging on the following line

> multiboot /tboot.gz <file:///tboot.gz> placeholder
> logging=vga,memory,serial
> module /xen.gz <file:///xen.gz> placeholder console=none

> module...
> module...
> module...
> # Append this line after the last module. If this line is not there it
> will boot correctly but it will not set the PCR values 17 to 19
> module /i5_i7_DUAL_SINIT_51.BIN
>
> If everything went fine, when you reboot you should have the following
> PCR values set:
>
> PCR 0-3: BIOS, Option ROMs, Platform Config
> PCR 4 : MBR (Grub stage1)
> PCR 5-7: OEM-specific, probably safe to skip
>

So, these were actually filled by the BIOS (not GRUB2).

> Additionnaly, tboot added the following PCR values (depending on the
> tboot config : DA mapping can be enabled if the following is used on
> tboot command line: pcr_map=da for pcr_map=da|legacy)
>
> The PCR values added by tboot are the following (the comments comes from
> my own analysis, extrapoled from TBoot PCR mapping documentation in
> /usr/share/doc/tboot-1.7.0/README)
>
> # Legacy PCR Tboot mapping
> PCR-17 : tboot policy control value, tboot policy (not changed anyway so
> we don't care ?)
> PCR-18 : tboot.gz (lcp_mlehash), grub.conf first module (xen.gz)
> PCR-19 : all other modules
>
> # Details / Authorities PCR Mapping (DA)
> PCR-17: tboot policycontrol value, tboot policy, first grub.conf modules
> (xen), all other modules
> PCR-18: tboot policycontrol value, tboot policy
>
> It seems to use a legacy mapping by default. I observed changes in the
> PCR value (by adding vga_delay=10 in the tboot line to read all the
> tboot details) and it effectivelly change the PCR 19 value.
>

Normally SINIT hash goes also into PCR17, but with this new DA option,
according to [1], the SINIT's authority (so, apparently the Intel's
public key used for signing those modules), now goes into PCR18,
allowing users to say: seal my secrets to any SINIT module which is
signed by the Intel's public key. Which apparently is to make it easy
for users to patch their buggy SINITs without the need to reseal to new
PCR values, e.g. as in case of the attack described in [2]. Although I
fail to see how this could be used in the case of this very attack,
which, as we described in the paper, required much more work from Intel
to patch.

[1] http://hg.code.sf.net/p/tboot/code/file/7e8dd5f8b1cd/README

[2]
http://www.invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf

> Now the questions/comments are:
>
> - PCR-8 (grub stage2) and so on until PCR-12 are not set. Is it a risk
> knowing that tboot fill PCR-18 and PCR-19 with most of the required
> hashes ?

tboot implements *Dynamic* Root of Trust for Measurements (DRTM), not a
static one. DRTM is an alternative to SRTM, as discussed in many papers
and presentations (also by ITL). In practice DRTM requires STM to be
complete, otherwise it ca be bypassed if somebody has a working SMM
exploit. Depending on the specific BIOS this might range from being
moderately difficult up to being very difficult. But generally not
impossible. As I we (ITL) discussed many times.

> - I don't use tboot policy mecanism, and I don't set any policy (all
> hashes related to the policies are set to 0). These policies are
> apparently used for dynamic boot verification using TXT or something
> like this. If I remember the antievilmaid terminology, we want the
> static variant. Is it correct?

LCP policies, generally, don't improve security guarantees that are
otherwise provided by "pure" TXT based on sealing and/or remote
attestation. In other words, if the attacker can attack "pure" TXT,
there is no benefit of using additional LCP policies. And if "pure" TXT
is well used (e.g. system boot is made conditional on ability to unseal
some secret from the TPM), then LCP doesn't offer any advanatge either.

But the name itself, Launch Control Polices, certainly sounds serious
and makes all those suite-clad sales folks to pee from excitement ;)

> - It seems like I need to use this SINIT module downloaded from intel
> web site. If not, I'm not able to fill PCR-18 and PCR-19. I think it
> force use of the intel TXT technology somehow. What about non intel
> processors ? How can I trust this binary module ? What are the risks here ?

More info about SINIT modules, its role, etc, can be found in the
previously quoted paper on attacking bugs in SINIT modules [2].

> - If tboot fill correctly PCR17-to-PCR19, can I seal my secret with
> PCR0-to-3 and PCR17-to-PCR19 ?
>

I would argue that it makes no sense to seal to PCR0-3 if you don't have
a SRTM-capable GRUB. In that case the GRUB cannot measure the
configuration and can be forced to load whatever modules the attacker
asks it to load, and so the SRTM is broken anyway. Again, DRTM should be
enough, so ideally we should just not worry about SRTM chain. Except for
the small issue that we don't have STM yet (or do we?) and so we
actually should...

> Sorry with all the things that are uncertain. I concentrated on the
> technical part, and now I have to study more in details the
> anti-evil-maid concept. Maybe you can help me there :P
>

The use of tboot, with its inherent DRTM scheme (aka Intel TXT), allows
us now to ignore the fact that the GRUB2 (or whatever other boot load we
might want to have) is not trusted boot-aware (which GRUB2 indeed is
not). And this is very good. Previously AEM had to use TrusteGRUB
instead of GRUB1. Such replacing of GRUB1->TrustedGRUB apparently worked
fine with previous Qubes versions which were based on fc13 Dom0. Now
that we use fc18 Dom0 it's not longer so straightforward.

Additionally by using tboot (and so Intel TXT) we no longer need to
trust that the boot loader (such as TrustedGRUB) is correctly written,
e.g. that it does the measurements correctly, doesn't have overflows,
etc. I certainly am willing to trust Intel's tboot code more than
TrustedGRUB code.

Also, in an ideal world, the use of Intel TXT should also allow us to
get rid of the BIOS from the trust chain. One cannot underestimate how
good that is! However, in practice, without a well written STM this is
not entirely possible (to not trust the BIOS). But in a classic SRTM
scheme we also need to trust the BIOS, so I don't see any problem with that.

And yet additionally, tboot/TXT provides us with an ability to make Cold
Boot attacks very hard, because Intel TXT aware chipset should
automatically block access to DRAM in the even of unclean system
shutdown. In that case the access should be blocked until the BIOS
executed Intel's authorized SCLEAN module, whose job is to scrap DRAM.

The disadvantage of tboot, as I understand are the following:
1) Only Intel systems support Intel TXT and so tboot
2) ... and yet still, not all systems(?) do really support TXT (or do they?)
3) If the BIOS is incorrectly written (incompatible with TXT), then an
unclean shutdown will brick our box.

Having that said, I think that a tboot-based AEM is a right choice.

Olivier, thanks for the patches, I will take a look at them somehow soon
and let you know my comments/questions.

Thanks,
joanna.

[Joanna Rutkowska]

Ok, one scenario that might be an example of how SRTM could sometimes
catch an attack, while DRTM cannot -- image we have an SMM exploit that,
however, doesn't allow to break the SRTM chain. In that case if we had
SRTM we would prevent the attack, but with DRTM (and without STM) we
will not.

But then again, I would worry less about such SMM attacks than I worry
about trusting: 1) if the BIOS correctly implements SRTM, and 2) if a
TrustedGRUB-like software correctly implements further SRTM extension.

Besides: Intel Trusted Execution Technology really sounds more serious
than TriustedGRUB ;)

> And yet additionally, tboot/TXT provides us with an ability to make Cold
> Boot attacks very hard, because Intel TXT aware chipset should
> automatically block access to DRAM in the even of unclean system
> shutdown. In that case the access should be blocked until the BIOS
> executed Intel's authorized SCLEAN module, whose job is to scrap DRAM.
>
> The disadvantage of tboot, as I understand are the following:
> 1) Only Intel systems support Intel TXT and so tboot
> 2) ... and yet still, not all systems(?) do really support TXT (or do they?)
> 3) If the BIOS is incorrectly written (incompatible with TXT), then an
> unclean shutdown will brick our box.
>
> Having that said, I think that a tboot-based AEM is a right choice.
>
> Olivier, thanks for the patches, I will take a look at them somehow soon
> and let you know my comments/questions.
>
> Thanks,
> joanna.
>

joanna.

[Joanna Rutkowska]

Olivier, and can you also update antievilmaid_install script, the
README, and also we can get rid of the TrustedGRUB now?

joanna.

[Olivier Médoc]

OK, I will check that, thanks for all the explanations and references.

So now I have to modify the antievilmaid scripts and README file to use
PCR17-to-PCR19 only. The second thing is to change the antievilmaid
setup script to install and reconfigure grub2+tboot on the USB key.

What are your recommendations related to intel SINIT modules knowing
it's licensed ? Should I include all the available modules directly
inside the AEM package with the license file ? Or should I ask the user
to download it himself so that he accept the license ?

On 06/25/13 11:32, Joanna Rutkowska wrote:

> On 06/25/13 11:21, Joanna Rutkowska wrote:

[Joanna Rutkowska]

On 06/25/13 11:53, Olivier Médoc wrote:
> OK, I will check that, thanks for all the explanations and references.
>
> So now I have to modify the antievilmaid scripts and README file to use
> PCR17-to-PCR19 only. The second thing is to change the antievilmaid
> setup script to install and reconfigure grub2+tboot on the USB key.
>
> What are your recommendations related to intel SINIT modules knowing
> it's licensed ? Should I include all the available modules directly
> inside the AEM package with the license file ? Or should I ask the user
> to download it himself so that he accept the license ?
>

Perhaps it would be safer to just leave that step to the user. Also not
to mix the GPL code (AEM) with non-GPL code. So, just add instructions
in the README.

joanna.

>
> On 06/25/13 11:32, Joanna Rutkowska wrote:
>> On 06/25/13 11:21, Joanna Rutkowska wrote:

[Olivier Médoc]

Here is the tboot patch for reference.

I didn't tried to compile it yet, and there are still some bugs:

- Booting with kernel 3.9.2 hangs after removing the antievilmaid key. I
don't know the reason. Maybe I broke something when playing with dracut
scripts, maybe my system is unclean because of the anti-evil-maid
testing. Kernel 3.7 seems to work, but again, it's based on the manual
scripts work, not based on the rpm package generated using this patch...

- When booting with antievilmaid, dom0 use 100% of the memory and it
takes some time before it can release the memory to the other VM.
Because of that, the netvm and firewallvm don't start automatically. I
don't know the reason yet.


On 06/25/13 20:02, Joanna Rutkowska wrote:

> On 06/25/13 11:53, Olivier M�doc wrote:
>> OK, I will check that, thanks for all the explanations and references.
>>
>> So now I have to modify the antievilmaid scripts and README file to use
>> PCR17-to-PCR19 only. The second thing is to change the antievilmaid
>> setup script to install and reconfigure grub2+tboot on the USB key.
>>
>> What are your recommendations related to intel SINIT modules knowing
>> it's licensed ? Should I include all the available modules directly
>> inside the AEM package with the license file ? Or should I ask the user
>> to download it himself so that he accept the license ?
>>
> Perhaps it would be safer to just leave that step to the user. Also not
> to mix the GPL code (AEM) with non-GPL code. So, just add instructions
> in the README.
>
> joanna.
>
>
>> On 06/25/13 11:32, Joanna Rutkowska wrote:
>>> On 06/25/13 11:21, Joanna Rutkowska wrote:

[Olivier Médoc]

Hum...

Forgot to remove references to trusted grub in make...

On 06/25/13 20:02, Joanna Rutkowska wrote:

> On 06/25/13 11:53, Olivier M�doc wrote:
>> OK, I will check that, thanks for all the explanations and references.
>>
>> So now I have to modify the antievilmaid scripts and README file to use
>> PCR17-to-PCR19 only. The second thing is to change the antievilmaid
>> setup script to install and reconfigure grub2+tboot on the USB key.
>>
>> What are your recommendations related to intel SINIT modules knowing
>> it's licensed ? Should I include all the available modules directly
>> inside the AEM package with the license file ? Or should I ask the user
>> to download it himself so that he accept the license ?
>>
> Perhaps it would be safer to just leave that step to the user. Also not
> to mix the GPL code (AEM) with non-GPL code. So, just add instructions
> in the README.
>
> joanna.
>
>
>> On 06/25/13 11:32, Joanna Rutkowska wrote:
>>> On 06/25/13 11:21, Joanna Rutkowska wrote:

[Olivier Médoc]

Hello, I finally got something stable. I attached all the additionnal
patches.

One of the bugs I encountered is a problem with plymouth hide-splash
command which apparently breaks the tty (I cannot switch back to the
splash screen -using the escape key- and I don't see any output). I just
remove the splash-screen command. The consequence is that the user has
to switch to the console to see the unsealed secret or the message
asking to remove the usb key.

On 06/26/13 12:46, Olivier M�doc wrote:
> Here is the tboot patch for reference.
>
> I didn't tried to compile it yet, and there are still some bugs:
>
> - Booting with kernel 3.9.2 hangs after removing the antievilmaid key.
> I don't know the reason. Maybe I broke something when playing with
> dracut scripts, maybe my system is unclean because of the
> anti-evil-maid testing. Kernel 3.7 seems to work, but again, it's
> based on the manual scripts work, not based on the rpm package
> generated using this patch...
>

I think I identified the problem:
Kernel 3.9.2 has a new module called ehci-pci. Both modules ehci-hcd and
ehci-pci are required to detect a USB2 key. Now, if I look in
/usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh, the only
module loaded inside this script is ehci-hcd.

Is it possible to add ehci-pci in this script so that keys plugged in
USB2 slots are detected ? Note that keys plugged in USB3 slots are
already detected.

EDIT: I can confirm that I works when I add ehci-pci next to ehci-hcd
inside /usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh. Just
have the regenerate the initram using dracut.

> - When booting with antievilmaid, dom0 use 100% of the memory and it
> takes some time before it can release the memory to the other VM.
> Because of that, the netvm and firewallvm don't start automatically. I
> don't know the reason yet.

I confirm this problem. After some minutes, the memory is released and
netvm and firewall vms start automatically. Can it be related to PCI
device release ?

[Joanna Rutkowska]

Hi Olivier,

I've finally found some time to read your code, and merge and build it.

Have a look at the code here:
http://git.qubes-os.org/?p=joanna/antievilmaid.git;a=summary

I've also built and uploaded rpms into our current-testing repo.

However, I still haven't tested it -- I will need some more time to do
that. Of course others are encouraged to test it in the meantime.

Many thanks for the contribution!

joanna.

On 06/28/13 17:10, � wrote:
> Hello, I finally got something stable. I attached all the additionnal
> patches.
>
> One of the bugs I encountered is a problem with plymouth hide-splash
> command which apparently breaks the tty (I cannot switch back to the
> splash screen -using the escape key- and I don't see any output). I just
> remove the splash-screen command. The consequence is that the user has
> to switch to the console to see the unsealed secret or the message
> asking to remove the usb key.
>

>>> On 06/25/13 11:53, Olivier Médoc wrote:
>>>> OK, I will check that, thanks for all the explanations and references.
>>>>
>>>> So now I have to modify the antievilmaid scripts and README file to use
>>>> PCR17-to-PCR19 only. The second thing is to change the antievilmaid
>>>> setup script to install and reconfigure grub2+tboot on the USB key.
>>>>
>>>> What are your recommendations related to intel SINIT modules knowing
>>>> it's licensed ? Should I include all the available modules directly
>>>> inside the AEM package with the license file ? Or should I ask the user
>>>> to download it himself so that he accept the license ?
>>>>
>>> Perhaps it would be safer to just leave that step to the user. Also not
>>> to mix the GPL code (AEM) with non-GPL code. So, just add instructions
>>> in the README.
>>>
>>> joanna.
>>>
>>>
>>>> On 06/25/13 11:32, Joanna Rutkowska wrote:
>>>>> On 06/25/13 11:21, Joanna Rutkowska wrote: