Bug Reports: AEM in Qubes

3,213 views
Skip to first unread message

David Hobach

unread,
Feb 24, 2014, 12:26:14 PM2/24/14
to qubes...@googlegroups.com
Dear developers,

Let me first explain my setup:
Dual boot (latest Qubes with all patches + Windows for gaming) desktop
machine --> AEM seemed a reasonable choice for me. As it is a desktop
machine, I didn't want to go for the USB stick solution, but rather use
another password to unseal the TPM. AEM was meant to be installed to the
/boot partition.

During the AEM installation I discovered the following two bugs:

1. The AEM installer doesn't support a direct installation to /boot as
needed for my setup (and as indicated by the README). After reading
through the installer script I noticed I didn't want to re-format my
/boot partition... I managed to get around this problem though.

2. The tpm_unsealdata during boot doesn't work if a password is
specified for TPM operations.
Reason: It doesn't have access to stdin to read the password as
a) The service is not configured to have access to stdin (explicitly set
to "null" in the config).
b) Reading from stdin during the boot process seems to be a lot
different than reading from it during normal OS runtime. stdin seems to
be managed by plymouth and/or systemd depending on whether plymouth is
used or not. Therefore commands reading from stdin during the boot
process are usually wrapped inside other functions to accomplish the
plymouth/systemd hassle. This is e.g. done that way for the cryptsetup
operations.

I fixed 2. a) + b) for my setup (I didn't test others). You can find the
patched files attached.

My kernel parameters fyi:
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0
rd.luks.uuid=luks-184b810f-55df-4198-ae45-07843a9699b4 $([ -x
/usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param ||
vconsole.keymap=de rd.lvm.lv=qubes_dom0/root rd.antievilmaid.asksrkpass
rd.antievilmaid.dontforcestickremoval plymouth.enable=0"

Thanks for your good work at Qubes!

Kind Regards
David
anti-evil-maid.service
anti-evil-maid.sh

Marek Marczykowski-Górecki

unread,
Feb 28, 2014, 8:00:41 AM2/28/14
to David Hobach, qubes...@googlegroups.com
On 24.02.2014 18:26, David Hobach wrote:
> Dear developers,
>
> Let me first explain my setup:
> Dual boot (latest Qubes with all patches + Windows for gaming) desktop
> machine --> AEM seemed a reasonable choice for me. As it is a desktop
> machine, I didn't want to go for the USB stick solution, but rather use
> another password to unseal the TPM. AEM was meant to be installed to the
> /boot partition.
>
> During the AEM installation I discovered the following two bugs:
>
> 1. The AEM installer doesn't support a direct installation to /boot as
> needed for my setup (and as indicated by the README). After reading
> through the installer script I noticed I didn't want to re-format my
> /boot partition... I managed to get around this problem though.

The whole idea of AEM is that it isn't accessible to the (another) running
system, especially in dual-boot setup. Otherwise your other system can conduct
multistage EM attack.

> 2. The tpm_unsealdata during boot doesn't work if a password is
> specified for TPM operations.
> Reason: It doesn't have access to stdin to read the password as
> a) The service is not configured to have access to stdin (explicitly set
> to "null" in the config).
> b) Reading from stdin during the boot process seems to be a lot
> different than reading from it during normal OS runtime. stdin seems to
> be managed by plymouth and/or systemd depending on whether plymouth is
> used or not. Therefore commands reading from stdin during the boot
> process are usually wrapped inside other functions to accomplish the
> plymouth/systemd hassle. This is e.g. done that way for the cryptsetup
> operations.
>
> I fixed 2. a) + b) for my setup (I didn't test others). You can find the
> patched files attached.

Thanks, I'll look at it and most likely apply.

> My kernel parameters fyi:
> GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0
> rd.luks.uuid=luks-184b810f-55df-4198-ae45-07843a9699b4 $([ -x
> /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param ||
> vconsole.keymap=de rd.lvm.lv=qubes_dom0/root rd.antievilmaid.asksrkpass
> rd.antievilmaid.dontforcestickremoval plymouth.enable=0"
>
> Thanks for your good work at Qubes!
>
> Kind Regards
> David


--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

signature.asc

David Hobach

unread,
Feb 28, 2014, 12:40:00 PM2/28/14
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
On 02/28/2014 02:00 PM, Marek Marczykowski-Górecki wrote:
> On 24.02.2014 18:26, David Hobach wrote:
>> Dear developers,
>>
>> Let me first explain my setup:
>> Dual boot (latest Qubes with all patches + Windows for gaming) desktop
>> machine --> AEM seemed a reasonable choice for me. As it is a desktop
>> machine, I didn't want to go for the USB stick solution, but rather use
>> another password to unseal the TPM. AEM was meant to be installed to the
>> /boot partition.
>>
>> During the AEM installation I discovered the following two bugs:
>>
>> 1. The AEM installer doesn't support a direct installation to /boot as
>> needed for my setup (and as indicated by the README). After reading
>> through the installer script I noticed I didn't want to re-format my
>> /boot partition... I managed to get around this problem though.
>
> The whole idea of AEM is that it isn't accessible to the (another) running
> system, especially in dual-boot setup. Otherwise your other system can conduct
> multistage EM attack.

Marek, can you please explain this a little bit more (i.e. multistage EM
attack)?

According to my understanding I'd notice changes to the BIOS and /boot
due to the AEM setup. Now if the attacker goes after the SRK password
with an EM attack, my secret phrase wouldn't display anymore. He'd get
the SRK password, but ideally I would throw away my mainboard afterwards
and certainly wouldn't enter my disk encryption password. In particular
he cannot seal the TPM again with my phrase as he doesn't know the phrase.
Of course, without SRK password he can simply unseal from within
Windows, change my boot process, seal again and launch an EM attack to
get the password for the encrypted Qubes drive.

In practice however I already noticed that changes to the grub.cfg
didn't make my secret phrase not being displayed for some reason...

Kind Regards
David

Marek Marczykowski-Górecki

unread,
Feb 28, 2014, 1:26:26 PM2/28/14
to David Hobach, qubes...@googlegroups.com
On 28.02.2014 18:40, David Hobach wrote:
> On 02/28/2014 02:00 PM, Marek Marczykowski-Górecki wrote:
>> On 24.02.2014 18:26, David Hobach wrote:
>>> Dear developers,
>>>
>>> Let me first explain my setup:
>>> Dual boot (latest Qubes with all patches + Windows for gaming) desktop
>>> machine --> AEM seemed a reasonable choice for me. As it is a desktop
>>> machine, I didn't want to go for the USB stick solution, but rather use
>>> another password to unseal the TPM. AEM was meant to be installed to the
>>> /boot partition.
>>>
>>> During the AEM installation I discovered the following two bugs:
>>>
>>> 1. The AEM installer doesn't support a direct installation to /boot as
>>> needed for my setup (and as indicated by the README). After reading
>>> through the installer script I noticed I didn't want to re-format my
>>> /boot partition... I managed to get around this problem though.
>>
>> The whole idea of AEM is that it isn't accessible to the (another) running
>> system, especially in dual-boot setup. Otherwise your other system can conduct
>> multistage EM attack.
>
> Marek, can you please explain this a little bit more (i.e. multistage EM attack)?
>
> According to my understanding I'd notice changes to the BIOS and /boot due to
> the AEM setup. Now if the attacker goes after the SRK password with an EM
> attack, my secret phrase wouldn't display anymore.

At this point the attacker can store SRK password somewhere, restore original
/boot state and show you some random innocent error, or simply reset/poweroff
machine with hope that you will not suspect anything. But ok, this is much
easier to spot.

> He'd get the SRK password,
> but ideally I would throw away my mainboard afterwards and certainly wouldn't
> enter my disk encryption password. In particular he cannot seal the TPM again
> with my phrase as he doesn't know the phrase.
> Of course, without SRK password he can simply unseal from within Windows,
> change my boot process, seal again and launch an EM attack to get the password
> for the encrypted Qubes drive.
>
> In practice however I already noticed that changes to the grub.cfg didn't make
> my secret phrase not being displayed for some reason...

I don't remember details, perhaps only kernel cmdline (along with kernel
binary and initrd) is used, not the whole grub.cfg?
signature.asc

David Hobach

unread,
Mar 1, 2014, 6:15:29 AM3/1/14
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
Good point Marek, thanks!

So in the end it's technically possible to detect the changes, but the
human factor is likely to make everything fail again anyway with a
dual-boot setup.

For a single-boot setup in contrast it would be harder for the attacker
to be able to accomplish the unseal -> read phrase + change boot process
-> seal again process using the attack mentioned above as he cannot
execute code without being detected (boot process integrity is checked,
Qubes encrypted), i.e. the maid would have to physically exist (no
malware) and sneak in at least once more (1st time: install EM for SRK,
which in the end removes code from /boot + reboots; 2nd time: retrieve
SRK, unseal etc., install EM for encrypted HD; 3rd time: retrieve
encrypted HD password).

>> He'd get the SRK password,
>> but ideally I would throw away my mainboard afterwards and certainly wouldn't
>> enter my disk encryption password. In particular he cannot seal the TPM again
>> with my phrase as he doesn't know the phrase.
>> Of course, without SRK password he can simply unseal from within Windows,
>> change my boot process, seal again and launch an EM attack to get the password
>> for the encrypted Qubes drive.
>>
>> In practice however I already noticed that changes to the grub.cfg didn't make
>> my secret phrase not being displayed for some reason...
>
> I don't remember details, perhaps only kernel cmdline (along with kernel
> binary and initrd) is used, not the whole grub.cfg?

This makes me think a USB stick with read-only switch for /boot might
even be better for my setup.

Marek Marczykowski-Górecki

unread,
Mar 1, 2014, 9:26:57 AM3/1/14
to David Hobach, qubes...@googlegroups.com
And be sure that you're booting from the stick, not from its copy on HD...
This is why its recommended to connect AEM stick only for booting and remove
it as soon as possible.
signature.asc

cprise

unread,
Mar 10, 2014, 12:42:20 PM3/10/14
to Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com
I am also having a problem with AEM. I used a custom SRK password and
right at the point in the boot process where I'd expect a password
prompt, the boot sequence just halts (about 1/10 the way on the boot
progress bar).

When building the AEM boot partition, for each kernel in the boot
options it prints "F: Failed to install module fpu".

David Hobach

unread,
Mar 10, 2014, 1:04:39 PM3/10/14
to cprise, qubes...@googlegroups.com
> I am also having a problem with AEM. I used a custom SRK password and
> right at the point in the boot process where I'd expect a password
> prompt, the boot sequence just halts (about 1/10 the way on the boot
> progress bar).

Are you using plymouth?
It didn't work with plymouth for me neither (that's why I submitted the
patch). Check what it says on the console (F1 I think) and try pressing
return, Ctrl+C or whatever to check if booting continues then.

> When building the AEM boot partition, for each kernel in the boot
> options it prints "F: Failed to install module fpu".

That's nothing to be concerned about if I remember correctly.

cprise

unread,
Mar 10, 2014, 9:38:15 PM3/10/14
to David Hobach, qubes...@googlegroups.com, Marek Marczykowski

On 03/10/14 13:04, David Hobach wrote:
>> I am also having a problem with AEM. I used a custom SRK password and
>> right at the point in the boot process where I'd expect a password
>> prompt, the boot sequence just halts (about 1/10 the way on the boot
>> progress bar).
>
> Are you using plymouth?
> It didn't work with plymouth for me neither (that's why I submitted
> the patch). Check what it says on the console (F1 I think) and try
> pressing return, Ctrl+C or whatever to check if booting continues then.

Thanks David. I suppose I am using plymouth, as I haven't changed
anything about the startup process except install AEM. However, I've
tried another AEM install using 'tpm_takeownership -y -z' for the
default password and ran into the same problem: The boot process halts
early.

I'll try your patches and suggestions, though I'm not sure where your
kernel parameter for plymouth would go; the assignment in your initial
message doesn't look like a grub config to me.

cprise

unread,
Mar 10, 2014, 10:55:04 PM3/10/14
to David Hobach, qubes...@googlegroups.com, Marek Marczykowski
OK, I've got AEM boot sort-of working with David's patches and plymouth
disabled (I just added the assignment to the 'module' lines in
grub.conf). I also turned off 'quiet'.

Problem is that its still hanging, and I believe its the same spot as
before. Only now I know that the spot is right after the passphrase is
printed. So I have to press Ctrl-C to continue boot sequence and get to
the LUKS prompt...

How come?

IIRC, the Trackpoint device is initialized right around this spot as
well. I'm concerned I may be messing up my boot sequence by interrupting
a program with Ctrl-C.

David Hobach

unread,
Mar 11, 2014, 1:08:25 PM3/11/14
to cprise, qubes...@googlegroups.com

On 03/11/14 03:55, cprise wrote:
> OK, I've got AEM boot sort-of working with David's patches and plymouth
> disabled (I just added the assignment to the 'module' lines in
> grub.conf). I also turned off 'quiet'.
>
> Problem is that its still hanging, and I believe its the same spot as
> before. Only now I know that the spot is right after the passphrase is
> printed. So I have to press Ctrl-C to continue boot sequence and get to
> the LUKS prompt...
>
> How come?

Did you apply the dracut patches which I attached to the initial mail
and did you run dracut -f to update your initramfs afterwards?
Sounded like you just edited /etc/default/grub.

Are you talking about the TPM passphrase prompt or about the LUKS one?

> IIRC, the Trackpoint device is initialized right around this spot as
> well. I'm concerned I may be messing up my boot sequence by interrupting
> a program with Ctrl-C.

If it's the tpm unseal prompt, this won't harm anything. It'll not
authenticate your machine to you though (i.e. it makes AEM + TPM useless).

cprise

unread,
Mar 11, 2014, 3:03:13 PM3/11/14
to David Hobach, qubes...@googlegroups.com

On 03/11/14 13:08, David Hobach wrote:
>
> On 03/11/14 03:55, cprise wrote:
>> OK, I've got AEM boot sort-of working with David's patches and plymouth
>> disabled (I just added the assignment to the 'module' lines in
>> grub.conf). I also turned off 'quiet'.
>>
>> Problem is that its still hanging, and I believe its the same spot as
>> before. Only now I know that the spot is right after the passphrase is
>> printed. So I have to press Ctrl-C to continue boot sequence and get to
>> the LUKS prompt...
>>
>> How come?
>
> Did you apply the dracut patches which I attached to the initial mail
> and did you run dracut -f to update your initramfs afterwards?
> Sounded like you just edited /etc/default/grub.
I replaced /usr/lib/dracut/modules.d/90anti-evil-maid/anti-evil-maid.sh
and /usr/lib/systemd/system/anti-evil-maid.service before re-running the
antievilmaid-install program. I'll try running 'dracut -f', though I
thought antievilmaid-install would have taken care of that.
>
> Are you talking about the TPM passphrase prompt or about the LUKS one?
The TPM passphrase. It seems to be unsealing and printing fine, and it
states that its using the default SRK password.

>
>> IIRC, the Trackpoint device is initialized right around this spot as
>> well. I'm concerned I may be messing up my boot sequence by interrupting
>> a program with Ctrl-C.
>
> If it's the tpm unseal prompt, this won't harm anything. It'll not
> authenticate your machine to you though (i.e. it makes AEM + TPM
> useless).
>
I don't see any sign of a prompt. The stoppage comes after the TPM
passphrase is printed and before the LUKS prompt.

Olivier Médoc

unread,
Mar 12, 2014, 3:32:16 AM3/12/14
to qubes...@googlegroups.com
The AEM script also waits for you to remove the USB disk, but plymouth
is so buggy that apparently nobody knowns how to print a message on
plymouth GUI mode.

That's also one of the reason why it shouldn't work if installed on the hdd.

Remove your USB key to see if it continue on.

I'll perform some additional tests with AEM to see if it still works on
some conditions, but it is hard to see the things you changes in the AEM
scripts. I'll have to make a diff on the original files.

Olivier Médoc

unread,
Mar 12, 2014, 3:34:50 AM3/12/14
to qubes...@googlegroups.com
On 03/11/14 20:03, cprise wrote:
>
In fact if you installed it on disk instead on usb, you should also add
the following to your kernel command line:
rd.antievilmaid.dontforcestickremoval

cprise

unread,
Mar 12, 2014, 9:37:49 AM3/12/14
to Olivier Médoc, qubes...@googlegroups.com, David Hobach
I've been using a stick, although the unpatched version of AEM never
printed a message about removing the stick (however, most of that time I
was looking at the plymouth screen not the console). The AEM
instructions should mention the need to switch to the console screen and
to remove the stick.

Now I have AEM working, but only with kernel 3.11.10. I need 3.7.4 to
avoid sudden system resets; Qubes is unstable without it. But booting
with AEM and 3.7.4 together, the system is unable to start any VMs and
says there is not enough memory. The free command shows 3.8 instead of
the normal 7.8 GB of total RAM.

I did generate the AEM stick while running 3.11.10... maybe that is the
difference?

Marek Marczykowski-Górecki

unread,
Mar 12, 2014, 10:13:59 AM3/12/14
to Olivier Médoc, qubes...@googlegroups.com
Indeed there is a problem with plymouth theme, I'm currently working on it.

>
> That's also one of the reason why it shouldn't work if installed on the hdd.
>
> Remove your USB key to see if it continue on.
>
> I'll perform some additional tests with AEM to see if it still works on some
> conditions, but it is hard to see the things you changes in the AEM scripts.
> I'll have to make a diff on the original files.


signature.asc

cprise

unread,
Mar 12, 2014, 10:23:09 AM3/12/14
to Marek Marczykowski-Górecki, Olivier Médoc, qubes...@googlegroups.com
The AEM installer could automatically disable plymouth.

Olivier Médoc

unread,
Mar 12, 2014, 12:11:06 PM3/12/14
to qubes...@googlegroups.com
Good luck :). I found that Debugging plymouth problems is very time
consuming. Maybe there is an easy way to restart plymouth and run a
script after the host has started, but in my attempts, it was crashing
my host most of the time...

Marek Marczykowski-Górecki

unread,
Mar 12, 2014, 5:50:45 PM3/12/14
to Olivier Médoc, qubes...@googlegroups.com
Yes, it is possible to debug it without constantly restarting the system:
https://wiki.ubuntu.com/Plymouth
signature.asc

Marek Marczykowski-Górecki

unread,
Mar 13, 2014, 9:51:20 PM3/13/14
to David Hobach, qubes...@googlegroups.com
On 24.02.2014 18:26, David Hobach wrote:
I've applied the changes with some modification: send the secret to plymouth
to show it on the screen (regardless of current mode - text of graphical splash).

Also I've finally managed to fix plymouth theme to show the messages - there
was missing plugin for actual rendering messages. This increased initrd size
by 10MB (sic!), but IMHO not a big problem.
Soon new qubes-logos (containing the plymouth theme) will be available.
signature.asc

Olivier Médoc

unread,
Mar 14, 2014, 5:33:34 AM3/14/14
to qubes...@googlegroups.com
Nice ! I will try this as soon as the package is available.

Thanks a lot, I was waiting for such improvement (my debugging attempts
on the plymouth theme failed with headaches).

David Hobach

unread,
Mar 14, 2014, 12:03:35 PM3/14/14
to qubes...@googlegroups.com
On 03/14/14 02:51, Marek Marczykowski-Górecki wrote:
Thanks Marek!
I'll test it once I find some time.


cprise

unread,
Mar 21, 2014, 5:55:30 AM3/21/14
to Marek Marczykowski-Górecki, Olivier Médoc, qubes...@googlegroups.com
FYI, the latest current-testing version of AEM just sort of rolls over
and plays dead: Booting in AEM mode just results in progression directly
to the LUKS prompt, and there is no sign in the console of trying to
unseal the secret.

Marek Marczykowski-Górecki

unread,
Mar 21, 2014, 6:01:37 AM3/21/14
to cprise, Olivier Médoc, qubes...@googlegroups.com
On 21.03.2014 10:55, cprise wrote:
> FYI, the latest current-testing version of AEM just sort of rolls over and
> plays dead: Booting in AEM mode just results in progression directly to the
> LUKS prompt, and there is no sign in the console of trying to unseal the secret.

Are you sure you've choosed AEM grub entry? Note that entries order have
changed - now AEM is the first one.
signature.asc

cprise

unread,
Mar 21, 2014, 6:10:21 AM3/21/14
to Marek Marczykowski-Górecki, Olivier Médoc, qubes...@googlegroups.com

On 03/21/14 06:01, Marek Marczykowski-Górecki wrote:
> On 21.03.2014 10:55, cprise wrote:
>> FYI, the latest current-testing version of AEM just sort of rolls over and
>> plays dead: Booting in AEM mode just results in progression directly to the
>> LUKS prompt, and there is no sign in the console of trying to unseal the secret.
> Are you sure you've choosed AEM grub entry? Note that entries order have
> changed - now AEM is the first one.
>

Yes, positive. I noticed the change. I also checked the grub parameters
by pressing 'e', and the rd.antievilmaid was there along with the line
for the .BIN file.

Marek Marczykowski-Górecki

unread,
Mar 21, 2014, 8:33:06 AM3/21/14
to cprise, Olivier Médoc, qubes...@googlegroups.com
Did you updated also qubes-logos package? Also check if initramfs contains
actual AEM module (you can use lsinitrd for that).
signature.asc

cprise

unread,
Mar 21, 2014, 1:36:02 PM3/21/14
to Marek Marczykowski-Górecki, Olivier Médoc, qubes...@googlegroups.com

On 03/21/14 08:33, Marek Marczykowski-Górecki wrote:
On 21.03.2014 11:10, cprise wrote:
On 03/21/14 06:01, Marek Marczykowski-Górecki wrote:
On 21.03.2014 10:55, cprise wrote:
FYI, the latest current-testing version of AEM just sort of rolls over and
plays dead: Booting in AEM mode just results in progression directly to the
LUKS prompt, and there is no sign in the console of trying to unseal the
secret.
Are you sure you've choosed AEM grub entry? Note that entries order have
changed - now AEM is the first one.

Yes, positive. I noticed the change. I also checked the grub parameters by
pressing 'e', and the rd.antievilmaid was there along with the line for the
.BIN file.
Did you updated also qubes-logos package? Also check if initramfs contains
actual AEM module (you can use lsinitrd for that).


It says qubes-logos-1.1-1-noarch is the latest version, and there seem to be 1 dracut module and 2 files present:

# lsinitrd /mnt/aem/initramfs-3.11.10-1.pvops.qubes.x86_64.img |grep evil
anti-evil-maid
-rw-r--r--   1 root     root          397 Mar 17 19:15 etc/udev/rules.d/69-anti-evil-maid.rules
-rwxr-xr-x   1 root     root         3685 Mar 17 19:15 usr/sbin/anti-evil-maid


David Hobach

unread,
Mar 29, 2014, 2:39:09 PM3/29/14
to qubes...@googlegroups.com
>>> I fixed 2. a) + b) for my setup (I didn't test others). You can find the
>>> patched files attached.
>>
>> I've applied the changes with some modification: send the secret to
>> plymouth
>> to show it on the screen (regardless of current mode - text of
>> graphical splash).
>>
>> Also I've finally managed to fix plymouth theme to show the messages -
>> there
>> was missing plugin for actual rendering messages. This increased
>> initrd size
>> by 10MB (sic!), but IMHO not a big problem.
>> Soon new qubes-logos (containing the plymouth theme) will be available.
>
> Thanks Marek!
> I'll test it once I find some time.


I tested the current version available via dom0 upgrade, but
unfortunately it doesn't work for me so far.
I ran dracut -f and updated my grub2.

It neither works with nor without plymouth. In particular I don't see
any password prompt and no other sign of AEM being active neither.

If anyone has a clue on what it might be or how to debug this problem,
please contact me.

My journalctl -a is attached.

Kind Regards
David
journalctl.log

cprise

unread,
Mar 29, 2014, 4:28:52 PM3/29/14
to David Hobach, qubes...@googlegroups.com, Marek Marczykowski
I reported the same problem on March 21:

On 21.03.2014 10:55, cprise wrote:

> FYI, the latest current-testing version of AEM just sort of rolls over and
> plays dead: Booting in AEM mode just results in progression directly to the
> LUKS prompt, and there is no sign in the console of trying to unseal the
> secret.

I may look in the boot image to see if an execute bit is missing somewhere.

Marek Marczykowski-Górecki

unread,
Mar 29, 2014, 6:55:29 PM3/29/14
to David Hobach, qubes...@googlegroups.com, Joanna Rutkowska, cprise
Thanks for the log, I've found the problem (bad filename in module-setup.sh
script). New package available in unstable repo, you can install it with:
sudo qubes-dom0-update --enablerepo=qubes-dom0-r2b3-unstable
'anti-evil-maid-dracut'

@joanna Can you upload new AEM package also to current-testing repo?
signature.asc

cprise

unread,
Mar 30, 2014, 2:34:59 AM3/30/14
to Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Joanna Rutkowska
Thanks Marek, this does work.

There is another problem, however, with AEM: Booting with it causes
about half of my RAM to disappear according to /proc/meminfo. I get into
situations when I am not able to start an appvm even if the only other
things running are netvm, firewallvm and one appvm (using around 3G).
This happens with both 3.7.4 and 3.11.10 kernels.

Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially
says there isn't enough memory to start netvm or firewallvm... if I then
start a small un-networked appvm I can start the service vms afterward.

My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s.
Kernel parameters are the default set by the AEM installer.

David Hobach

unread,
Mar 30, 2014, 7:32:58 AM3/30/14
to qubes...@googlegroups.com
Yes, that puts AEM back to life. Thanks! :-)

However there's one bug left:
With plymouth disabled (i.e. plymouth.enable=0 in /etc/default/grub &
grub.cfg) those /bin/plymouth message calls in anti-evil-maid.sh won't
do anything at all, i.e. they won't show the secret passphrase for
example. Calls to info [message] in contrast work for me. Maybe there's
a function that works for both variants or maybe it's possible to write
such a function?

@cprise: I suppose you use plymouth?

> There is another problem, however, with AEM: Booting with it causes
> about half of my RAM to disappear according to /proc/meminfo. I get into
> situations when I am not able to start an appvm even if the only other
> things running are netvm, firewallvm and one appvm (using around 3G).
> This happens with both 3.7.4 and 3.11.10 kernels.
>
> Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially
> says there isn't enough memory to start netvm or firewallvm... if I then
> start a small un-networked appvm I can start the service vms afterward.
>
> My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s.
> Kernel parameters are the default set by the AEM installer.

@cprise: I cannot confirm that with 3.11.1-2 and 16 GB RAM. Sometimes
the memory balancer however seems to make stupid decisions (it just
allocated 4GB RAM for my e-mail domain?) or claims there's nothing left.
Most of the time I could fix that by setting fixed memory limits though
using the Qubes VM Manager. In particular that already happened before
using the new AEM fix.

cprise

unread,
Mar 30, 2014, 2:54:28 PM3/30/14
to David Hobach, qubes...@googlegroups.com, Marek Marczykowski
Yes.

>
>> There is another problem, however, with AEM: Booting with it causes
>> about half of my RAM to disappear according to /proc/meminfo. I get into
>> situations when I am not able to start an appvm even if the only other
>> things running are netvm, firewallvm and one appvm (using around 3G).
>> This happens with both 3.7.4 and 3.11.10 kernels.
>>
>> Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially
>> says there isn't enough memory to start netvm or firewallvm... if I then
>> start a small un-networked appvm I can start the service vms afterward.
>>
>> My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s.
>> Kernel parameters are the default set by the AEM installer.
>
> @cprise: I cannot confirm that with 3.11.1-2 and 16 GB RAM. Sometimes
> the memory balancer however seems to make stupid decisions (it just
> allocated 4GB RAM for my e-mail domain?) or claims there's nothing
> left. Most of the time I could fix that by setting fixed memory limits
> though using the Qubes VM Manager. In particular that already happened
> before using the new AEM fix.
>
Maybe if I disable plymouth my other 4GB will return? LOL.

In my case it does appear to be a bug in either tboot or rd.antievilmaid
(or just maybe a bug in the way plymouth reacts to them).

Marek Marczykowski-Górecki

unread,
Mar 30, 2014, 3:12:47 PM3/30/14
to cprise, David Hobach, qubes...@googlegroups.com
/proc/meminfo (in dom0) shows only dom0 memory. All detected memory can be
shown by 'xl info' (total_memory field).

> I get into situations when
> I am not able to start an appvm even if the only other things running are
> netvm, firewallvm and one appvm (using around 3G).

Qmemman distribute *all* the system memory to the running VMs (included in
memory balancing). By default firewallvm and netvm are excluded from it. So if
you have two domains participating in memory balancing (dom0 and the other
appvm) its pretty normal that the one appvm got 3G - about half of all the memory.

> This happens with both
> 3.7.4 and 3.11.10 kernels.
>
> Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially says
> there isn't enough memory to start netvm or firewallvm... if I then start a
> small un-networked appvm I can start the service vms afterward.

This is the only possible problem here. Is it reproducible, or happened just once?

> My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s. Kernel
> parameters are the default set by the AEM installer.
>


signature.asc

cprise

unread,
Mar 31, 2014, 12:11:59 AM3/31/14
to Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com
5092 for AEM boot
7884 for non-AEM boot

Both times booting from the USB stick.

>
>> I get into situations when
>> I am not able to start an appvm even if the only other things running are
>> netvm, firewallvm and one appvm (using around 3G).
> Qmemman distribute *all* the system memory to the running VMs (included in
> memory balancing). By default firewallvm and netvm are excluded from it. So if
> you have two domains participating in memory balancing (dom0 and the other
> appvm) its pretty normal that the one appvm got 3G - about half of all the memory.
>
>> This happens with both
>> 3.7.4 and 3.11.10 kernels.
>>
>> Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially says
>> there isn't enough memory to start netvm or firewallvm... if I then start a
>> small un-networked appvm I can start the service vms afterward.
> This is the only possible problem here. Is it reproducible, or happened just once?
Its 100% reproducible.

>> My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s. Kernel
>> parameters are the default set by the AEM installer.
>>

2 more AEM problems.....

1. The installer prompt asking for uppercase 'YES' to proceed will
proceed /anyway/ if you only press Enter. It does show an error in the
process:
line 57: [: !=: unary operator expected

2. The Grub menu for AEM advanced options will default to Xen 1.4.5
instead of 1.4.6 when selecting the top choice for the hypervisor. I
have to cursor down to specifically select Xen 1.4.6.



Joanna Rutkowska

unread,
Mar 31, 2014, 4:45:20 AM3/31/14
to cprise, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com
On 03/30/14 08:34, cprise wrote:
>
If that's indeed what's happening the only component that might be
responsible for that would be tboot. I don't see this issue on my
system, but perhaps it's something system/processor dependent? I suggest
you consult this issue on tboot-devel mailing list.

joanna.

signature.asc

Joanna Rutkowska

unread,
Mar 31, 2014, 5:24:21 AM3/31/14
to Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, cprise
Done.
j.

signature.asc

Olivier Médoc

unread,
Mar 31, 2014, 1:31:02 PM3/31/14
to qubes...@googlegroups.com
I also had this problem with kernel 3.7.4 in the past. I though it was
caused by a bug of this kernel version because it works correctly with
the 3.11 serie.

cprise

unread,
Mar 31, 2014, 3:19:46 PM3/31/14
to Olivier Médoc, qubes...@googlegroups.com, Joanna Rutkowska
Yes, the service vms start without error under 3.11.10 + tboot... but
total memory is still limited to 5092MB.

Also, per Joanna's suggestion, tboot does appear to be the cause of the
total memory problem. I created a copy of the grub entry I've been
booting from, but removed the rd.antievilmaid reference on the linux
module line: The problem persists.

Joanna Rutkowska

unread,
Mar 31, 2014, 7:13:34 PM3/31/14
to cprise, Olivier Médoc, qubes...@googlegroups.com
Can you try with everything the same (xen, kernel, initramfs) but
without tboot in the grub entry, just to make sure it really is the cause?

joanna.

signature.asc

cprise

unread,
Mar 31, 2014, 10:20:20 PM3/31/14
to Joanna Rutkowska, Olivier Médoc, qubes...@googlegroups.com
OK... I restored the rd.antievilmaid reference, deleted the 'multiboot
tboot' line, changed the line for xen from 'module' to 'multiboot'. The
remaining module lines were for vmlinuz, initramfs and the SINIT .BIN
file. Now xl info shows 7884MB total RAM.

I also repeated this with the 3.11.10 kernel and initramfs and got the
same result. The service vms could start without problems for both
kernel versions.

Marek Marczykowski-Górecki

unread,
Apr 1, 2014, 2:38:45 PM4/1/14
to David Hobach, qubes...@googlegroups.com
I haven't found such function, but indeed it is really simple. I'll implement
this, but there are some higher prioritized things first.

BTW Why do you want to disable plymouth, since AEM works with it? You can
always see detailed boot in plymouth by pressing ESC.
signature.asc

David Hobach

unread,
Apr 3, 2014, 12:44:35 PM4/3/14
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
Thanks. I totally agree @prio.

> BTW Why do you want to disable plymouth, since AEM works with it? You can
> always see detailed boot in plymouth by pressing ESC.

Mostly for my convenience (I try to avoid pressing the same buttons day
to day).
Nevertheless it makes sense not to have plymouth as unnecessary
dependency of AEM from my point of view.

cprise

unread,
Apr 3, 2014, 11:33:43 PM4/3/14
to Joanna Rutkowska, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com
FYI, I've posted the problem to their list and gotten a partial
work-around from Jimmy. He seems intrigued that Qubes is making use of
tboot.

Adding the parameter 'min_ram=0x2000000' after tboot.gz got the missing
memory to re-appear, but the 'insufficient memory' errors remain when
starting vms from VM Manager about 1/2 the time; doesn't seem to be any
problem with qvm-start, however. Also, when I do get the netvm running,
there is sometimes a problem with network traffic being blocked (I might
test this more to see how repeatable it is).


Axon

unread,
May 17, 2014, 7:34:32 PM5/17/14
to Joanna Rutkowska, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
Some (hopefully constructive) feedback from a user's perspective after
working with AEM:

1. The requirement that the AEM USB stick be prepared in dom0 directly
contradicts the Qubes rule that USB devices should not be attached
directly to dom0. Correct me if I'm wrong, but it should be possible to
install AEM to a stick connected to an AppVM (USBVM). Presumably this
will be *required* once the USBVM is installed by default in Qubes.

2. The requirement that the Intel SINIT module be copied from an AppVM
to dom0 directly contradicts the Qubes rule that files should never be
copied from AppVMs to dom0 (as well as the more general security rule
that files should never be copied from less trusted to more trusted
security domains). I'm not sure if this one is avoidable (and I did read
the note about this in the doc), but please consider this in conjunction
with point 1 above. According to the AEM docs, the current procedure is
to copy the .BIN from the AppVM to dom0's /boot. Then the whole of /boot
is copied to the AEM stick. Can we instead copy /boot from dom0 to the
stick, then copy the .BIN from the AppVM directly to the stick? Really
anything is better than telling the user to download some weird binary
from the Internet and then copy it to dom0...

3. As noted by others, there does not appear to be an option in the AEM
installer to install to disk (rather than to a removable drive). The
installer states that the selected partition will be formatted before
/boot is copied to it, making it impossible (or just a really bad idea)
to select the /boot partition itself as the destination.

If installing to disk should not be an option, than that's fine, but in
that case the documentation and the installer itself should be clear
about this. (Currently, the docs and the installer both imply that
installing to disk is an option, and the source blog article[1] openly
discusses it as a viable option.)

4. Related to 3, the AEM installer won't accept RAID devices. It expects
input such as:

# /usr/lib/antievilmaid/antievilmaid_install /dev/sdc 1 /boot

which selects sdc1 as the destination.

If one attempts to choose a RAID device, such as /dev/md125, this fails,
because the second argument appears to be simply appended to the end of
the device name. So the installer complains that "md1251" (or more
generally "mdXY") is not a valid device, which of course it is not.


[1]http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html

signature.asc

Joanna Rutkowska

unread,
May 19, 2014, 6:44:08 AM5/19/14
to Axon, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
On 05/18/14 01:34, Axon wrote:
> Some (hopefully constructive) feedback from a user's perspective after
> working with AEM:
>
> 1. The requirement that the AEM USB stick be prepared in dom0 directly
> contradicts the Qubes rule that USB devices should not be attached
> directly to dom0. Correct me if I'm wrong, but it should be possible to
> install AEM to a stick connected to an AppVM (USBVM). Presumably this
> will be *required* once the USBVM is installed by default in Qubes.
>

It is possible to install everything in a USBVM except for doing the
final tpm_seal'ing. This is, naturally, because we don't virtualize TPM
to AppVMs currently.

But I think that doing this:
1) Create a fresh DispVM
2) Format your USB stick there and install AEM from this DispVM
3) Reboot the OS from the AEM stick, loging to Dom0, mount the stick
there and tpm_seal.

... should be reasonably secure, unless you don't trust this particular
stick *firmware* (as opposed to just its partition table, filesystem).
This is because it should get the trusted partition table, filesystem,
as long as you treat this DispVM as trusted (which you should, assuming
you trust the template).

Not 100% ideal, but "good enough" IMHO.

> 2. The requirement that the Intel SINIT module be copied from an AppVM
> to dom0 directly contradicts the Qubes rule that files should never be
> copied from AppVMs to dom0 (as well as the more general security rule
> that files should never be copied from less trusted to more trusted
> security domains). I'm not sure if this one is avoidable (and I did read
> the note about this in the doc), but please consider this in conjunction
> with point 1 above. According to the AEM docs, the current procedure is
> to copy the .BIN from the AppVM to dom0's /boot. Then the whole of /boot
> is copied to the AEM stick. Can we instead copy /boot from dom0 to the
> stick, then copy the .BIN from the AppVM directly to the stick? Really
> anything is better than telling the user to download some weird binary
> from the Internet and then copy it to dom0...
>

Yes, I think so, it should be no problem to copy SINITs as part of step
#1 outlined above. The SINIT files are loaded and executed by tboot
(processor's SENTER) only if they are properly signed by Intel (at least
this is what SDM days). So, this should not be a problem.

Of course we cannot just package SINITs together with AEM rpm(s) because
of licensing limitations.

> 3. As noted by others, there does not appear to be an option in the AEM
> installer to install to disk (rather than to a removable drive). The
> installer states that the selected partition will be formatted before
> /boot is copied to it, making it impossible (or just a really bad idea)
> to select the /boot partition itself as the destination.
>

IIRC this should work fine:

mv /boot /boot.orig

> If installing to disk should not be an option, than that's fine, but in
> that case the documentation and the installer itself should be clear
> about this. (Currently, the docs and the installer both imply that
> installing to disk is an option, and the source blog article[1] openly
> discusses it as a viable option.)
>
> 4. Related to 3, the AEM installer won't accept RAID devices. It expects
> input such as:
>
> # /usr/lib/antievilmaid/antievilmaid_install /dev/sdc 1 /boot
>
> which selects sdc1 as the destination.
>
> If one attempts to choose a RAID device, such as /dev/md125, this fails,
> because the second argument appears to be simply appended to the end of
> the device name. So the installer complains that "md1251" (or more
> generally "mdXY") is not a valid device, which of course it is not.
>
>

Pity. Hm, but that strange, because I remember my previous Vaio had such
device naming and yet I used AEM there without a problem...? Ah, perhaps
not, perhaps my BIOS was taking the /dev/mdXXX devices and was creating
a /dev/sda from them?

Anyway, do you have a patch to fix that?


> [1]http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html
>


joanna.

signature.asc

Axon

unread,
May 19, 2014, 11:15:23 AM5/19/14
to Joanna Rutkowska, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
Joanna Rutkowska:
> On 05/18/14 01:34, Axon wrote:
>> Some (hopefully constructive) feedback from a user's perspective after
>> working with AEM:
>>
>> 1. The requirement that the AEM USB stick be prepared in dom0 directly
>> contradicts the Qubes rule that USB devices should not be attached
>> directly to dom0. Correct me if I'm wrong, but it should be possible to
>> install AEM to a stick connected to an AppVM (USBVM). Presumably this
>> will be *required* once the USBVM is installed by default in Qubes.
>>
>
> It is possible to install everything in a USBVM except for doing the
> final tpm_seal'ing. This is, naturally, because we don't virtualize TPM
> to AppVMs currently.
>
> But I think that doing this:
> 1) Create a fresh DispVM
> 2) Format your USB stick there and install AEM from this DispVM
> 3) Reboot the OS from the AEM stick, loging to Dom0, mount the stick
> there and tpm_seal.
>

So, this would require temporarily stopping the USBVM and transferring
the USB controller back to dom0?

> ... should be reasonably secure, unless you don't trust this particular
> stick *firmware* (as opposed to just its partition table, filesystem).
> This is because it should get the trusted partition table, filesystem,
> as long as you treat this DispVM as trusted (which you should, assuming
> you trust the template).
>

Assuming you trust the template... and the USBVM? (I think we
established in a past thread[2] that the USBVM always has r/w access to
the stick, even when the stick is "attached" to the DispVM.)

> Not 100% ideal, but "good enough" IMHO.
>
>> 2. The requirement that the Intel SINIT module be copied from an AppVM
>> to dom0 directly contradicts the Qubes rule that files should never be
>> copied from AppVMs to dom0 (as well as the more general security rule
>> that files should never be copied from less trusted to more trusted
>> security domains). I'm not sure if this one is avoidable (and I did read
>> the note about this in the doc), but please consider this in conjunction
>> with point 1 above. According to the AEM docs, the current procedure is
>> to copy the .BIN from the AppVM to dom0's /boot. Then the whole of /boot
>> is copied to the AEM stick. Can we instead copy /boot from dom0 to the
>> stick, then copy the .BIN from the AppVM directly to the stick? Really
>> anything is better than telling the user to download some weird binary
>> from the Internet and then copy it to dom0...
>>
>
> Yes, I think so, it should be no problem to copy SINITs as part of step
> #1 outlined above.
>

Sorry, I'm not sure what your "yes" is referring to. Is it a yes to the
question of whether we can just copy the .BIN directly to the stick? I
must confess I'm also not sure which "step #1" you're referring to.
(Your step #1 above is just "Create a fresh DispVM," so I assume it must
be a different "step #1," but I don't see any others "above" where you
wrote that...).

> The SINIT files are loaded and executed by tboot
> (processor's SENTER) only if they are properly signed by Intel (at least
> this is what SDM days). So, this should not be a problem.

Hm, this sounds like you're saying that it should not be a problem to
copy the SINIT files to dom0 (since they're executed only if properly
signed), so maybe you weren't answering yes to my question after all...

> Of course we cannot just package SINITs together with AEM rpm(s) because
> of licensing limitations.
>
>> 3. As noted by others, there does not appear to be an option in the AEM
>> installer to install to disk (rather than to a removable drive). The
>> installer states that the selected partition will be formatted before
>> /boot is copied to it, making it impossible (or just a really bad idea)
>> to select the /boot partition itself as the destination.
>>
>
> IIRC this should work fine:
>
> mv /boot /boot.orig
>

Sorry, I'm not sure I understand. If I do that before selecting the
partition on which /boot resides, then how will the AEM installer copy
/boot to the stick?

>> If installing to disk should not be an option, than that's fine, but in
>> that case the documentation and the installer itself should be clear
>> about this. (Currently, the docs and the installer both imply that
>> installing to disk is an option, and the source blog article[1] openly
>> discusses it as a viable option.)
>>
>> 4. Related to 3, the AEM installer won't accept RAID devices. It expects
>> input such as:
>>
>> # /usr/lib/antievilmaid/antievilmaid_install /dev/sdc 1 /boot
>>
>> which selects sdc1 as the destination.
>>
>> If one attempts to choose a RAID device, such as /dev/md125, this fails,
>> because the second argument appears to be simply appended to the end of
>> the device name. So the installer complains that "md1251" (or more
>> generally "mdXY") is not a valid device, which of course it is not.
>>
>>
>
> Pity. Hm, but that strange, because I remember my previous Vaio had such
> device naming and yet I used AEM there without a problem...? Ah, perhaps
> not, perhaps my BIOS was taking the /dev/mdXXX devices and was creating
> a /dev/sda from them?
>

Actually, I don't know. I suppose you're right that the "mdXXX" naming
scheme isn't just for RAID devices; I only described it in terms of RAID
devices because that was my personal experience.

> Anyway, do you have a patch to fix that?
>

Sorry, I do not. I was just reporting my experience. On the bright side,
I would guess that very few, if any, prospective AEM users would want to
select a RAID device anyway, so it's probably not very important. (I
just try to report any information that I think might somehow be helpful.)

>
>> [1]http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html
[2]https://groups.google.com/d/topic/qubes-users/M8F8xDttOwA/discussion
>
>
> joanna.
>


signature.asc

cprise

unread,
May 19, 2014, 12:33:31 PM5/19/14
to qubes...@googlegroups.com, Axon, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc

Yeah, I think telling the user in the AEM instructions to unzip the SINIT files in an appvm would keep it secure. Copying the SINIT BIN file into Dom0 shouldn't be a problem: Its not a Linux executable and the execute bit won't be set anyway, so no accidental execution in the dom0 shell. Otherwise, the signature has to be good to be executed at all.
 

Axon

unread,
May 20, 2014, 1:00:30 AM5/20/14
to cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
cprise:
Did you mean "dispvm" rather than "appvm" here? (If you did mean
"appvm," then I'm not sure I see why that would keep it secure...)

> Copying the SINIT BIN file into
> Dom0 shouldn't be a problem: Its not a Linux executable and the execute bit
> won't be set anyway, so no accidental execution in the dom0 shell.
> Otherwise, the signature has to be good to be executed at all.

Ah, I see. I suppose it's OK to make an exception in this one case to
the "don't copy files to dom0" rule. :)

Well, the important thing is that each individual Qubes user gets to
decide for him/herself whether they are willing to make this exception
in order to reap the benefits of AEM (the value of which will differ
among individual user circumstances).


signature.asc

cprise

unread,
May 20, 2014, 11:33:32 PM5/20/14
to Axon, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
Its fine to copy files into dom0 in most cases where they have a trusted
signature (and, indeed, we are trusting Intel anyway). Package files get
copied into dom0 all the time, but that's OK because they're signed
packages. But in this case its the BIN file within the zip and not the
zip itself that is protected/signed.

As for unzipping, that implies the user is making the usual
Qubes-related decision about what is and isn't risky. Unzipping
downloaded files may be a bit risky, so choose an appvm ('untrusted' or
similar) or dispvm as seems appropriate.

Axon

unread,
May 21, 2014, 2:23:58 AM5/21/14
to cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
cprise:
This case actually seems quite different, though, because we have no way
to verify the signature ourselves (or to know whether the "SENTER
instruction of the processes" is correctly checking the signature).
We're also downloading the file by pointing our browsers to the HTTPS
Intel download page, so we're essentially trusting that we weren't the
victim of a MITM attack (e.g., forged cert). So, it's not the same as
trusting signed yum updates, and it's not the same as purchasing a
sealed, physical CPU from Intel (which we then have to trust), IMO.

So, maybe this case is a bit riskier, yes? But is the extra risk worth
it? For some people, it surely is. (For example, someone who travels a
lot and has to leave their laptop unattended in hotel rooms, where evil
maids might get to it.) For others, probably not. (For example, a Qubes
machine which always sits on a desk inside the locked house of someone
who lives alone.)
signature.asc

Daniel Lukes

unread,
May 21, 2014, 3:30:04 AM5/21/14
to Axon, cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We could perform a sha512sum of the respective SINITs we download, and
send them signed to this list.

If people are feeling generous, they could download many SINITs from the
SSL Intel page, and send the sums.
>
>
> So, maybe this case is a bit riskier, yes? But is the extra risk worth
> it? For some people, it surely is. (For example, someone who travels a
> lot and has to leave their laptop unattended in hotel rooms, where evil
> maids might get to it.) For others, probably not. (For example, a Qubes
> machine which always sits on a desk inside the locked house of someone
> who lives alone.)
>
>> As for unzipping, that implies the user is making the usual
>> Qubes-related decision about what is and isn't risky. Unzipping
>> downloaded files may be a bit risky, so choose an appvm ('untrusted' or
>> similar) or dispvm as seems appropriate.
>>
>

- --
Daniel Lukes (920)-901-9298 daniel...@yandex.ru
daniel...@openmailbox.org daniel...@opmbx.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTfFXoAAoJEBGF1xscz1OesPkP/39obr6YlZ7laaxqoaJVINhP
z6msOj3vK1EtceMtqAOr/bfKngZHA8NO0OY22CxpAaxTqifas8qKZc7ZRZUQ+aMn
UFBB8RhmDAyoqegN9i2Smu0zS//yuUSioUPArKOEhw2FPYJL6dElQYIZMtb0luAW
h6RYHJvIEfSlSLAvLVCzYsZT+IwOklY++6xbk/5Eq3K3q8w17qZ0vW0rfo35RTzv
ijYmbD0JK4LL4+hLKxGxZLHkwcrMfd07W99yIXnCzyfDch3WZIt449B84ajJZy6U
1d17ZvHoSZfKalQjoypwOiaCZNLa1u1SYlxmo5T2A7cNHc28kzT9cIeYWPaMk/P2
jrE/ReUWwQXYPeDt6JvScVljNNxE4czTqouz19+8KjBv+xDx4C6gua1nf2adMhEx
KjVytgYqWgq5BwWXFWc5lopZAnmSh/9pQ876k3VbR22U4iob7V8Xe4Vwj/OCQAPG
F3SBUZU+SxT/ULdYR1GMNwcgy0NEn3wU1wQRiPCi00MBRb1KhE4SRfUdi6wxFXP1
BJPSsRH4bj/v7mStKTa1qpY865ShFI6Ou4V81Ad5nS7OHeRJjnNt6I5U3meR+TwB
7UyRTw/b/B5s2XlfjewKR4iNhJD0QzYjAyRcrQPpIsbXSZP9ONXvTJSqTIbmJ8b4
/blA1LInUL5cH9m2F1ca
=DqAz
-----END PGP SIGNATURE-----

Daniel Lukes

unread,
May 21, 2014, 3:57:46 AM5/21/14
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



Axon:
We could perform a sha512sum of the respective SINITs we download, and
send them signed to this list.

If people are feeling generous, they could download many SINITs from the
SSL Intel page, and send the sums.

EDIT TO ADD: Meanwhile in conspiracy theories, TBird + Enigmail are
forcing SHA1 against my key prefs.
>
> So, maybe this case is a bit riskier, yes? But is the extra risk
> worth it? For some people, it surely is. (For example, someone who
> travels a lot and has to leave their laptop unattended in hotel
> rooms, where evil maids might get to it.) For others, probably
> not. (For example, a Qubes machine which always sits on a desk
> inside the locked house of someone who lives alone.)
>
>> As for unzipping, that implies the user is making the usual
>> Qubes-related decision about what is and isn't risky. Unzipping
>> downloaded files may be a bit risky, so choose an appvm
>> ('untrusted' or similar) or dispvm as seems appropriate.
>>
>

- --
Daniel Lukes (920)-901-9298 daniel...@yandex.ru
daniel...@openmailbox.org daniel...@opmbx.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTfFxwAAoJEBGF1xscz1OeGX4QALVEh9I8MCgtugeXQcrjTuwb
3SRvueb8yBIWBmp8HKRMPt3e/KfsxcqXkqw0L2yshC0WeZlu8JjR2A3lhNuNiHxq
pKYw9nwnnoeEk16BBIhgcXJOmy1QoVrk0c4+ECqDCWpa4+19gR6T7rlbBcQmD5to
tahDKBINwosXX0DAVGe+RVUELnBC3eJbFh7pPDwYxA0BJJj+BfCp5/NApWMqCYGm
/z25bQc17xcc/XZJXYfAkmnnBWpD+4FKyC/+bppxqFHU+dmCBW+W8elFtBPqi3Fh
6rZSTj3Kc5jkdOmd+pzWDHF3J6dCnP/RWIBCOpBR6Lo6EI3SjhEcqk12x1QvNQQi
ADsBgWkap0DUT3/j4WZJpxy5rvKG4vZN/zM9MEOL2USDXyqlo9V0XvQJI1shXDYZ
IrQhRMp4IT8K0IdA7i1p1G8OhUG5WqNLhP8kSVQMS34fg1Z2xl5kEX3CXRR8YoVo
AEfdIqRKJ9/CSCOEWBo1+3A50wIgjkTaWfXEA12+QkHulhm6/PuY4MQodvA9qfo7
NnOusAhhmrNCQK3z7pEiXhxrJ1k6Yq1+HxfaiF7U2Yjp8joyymU9CpRVM0OM43zO
G6eRuz0XYAIjTaAz9q4MVqeh5UtXyv9REup1WJxQ5suAQ29/X9eg9nUSgvQFvSES
YsgaTz/EOAk9aeEtIhRg
=9iyH
-----END PGP SIGNATURE-----

Axon

unread,
May 22, 2014, 4:47:34 PM5/22/14
to cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
Axon:
Some of you are thinking, "But what if someone sneaks into your house
(e.g., no-knock warrant) and performs an Evil Maid attack on you?"

If you have reason to believe that someone might sneak into your house
(and that you wouldn't notice afterward), then yes, that's a legitimate
concern for you. However, consider this: If someone can sneak into your
house, then they can also install a hidden pinhole camera somewhere
which records your keystrokes (or a hardware keylogger, or something
else which performs the same function of sniffing your typed passphrases).

"Fine," you say, "then I'll just use my AEM stick to supply a keyfile
for my LUKS encrypted system drive. This way, even if they somehow learn
my passphrase, they still won't be able to decrypt my system drive." The
only problem is that your *backup* doesn't require a keyfile (nor should
it, since a disaster which requires you to restore from the backup could
easily destroy all available copies of the keyfile). So, all the
attacker has to do is learn your backup passphrase and acquire a copy of
your encrypted backup file (which is probably pretty easy to do without
your notice if you're storing copies off-site, like you're supposed to).

Does anyone have a solution for this? :)
signature.asc

Axon

unread,
May 22, 2014, 5:14:45 PM5/22/14
to cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
Axon:
Sorry, I meant "sneak and peek warrant" here.
See: https://ssd.eff.org/your-computer/govt/sneak-and-peek
signature.asc

cprise

unread,
May 22, 2014, 9:24:52 PM5/22/14
to Axon, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
This is no longer talking about AEM bugs. However, it would be
interesting to hear if anyone does have a solution.

AFAIK, Qubes' "strong security" is focused against remote/network
threats. AEM is there to try to prevent the *easy* physical attacks from
succeeding.

Joanna Rutkowska

unread,
May 23, 2014, 8:13:09 AM5/23/14
to Axon, cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
On 05/22/14 22:47, Axon wrote:
> Some of you are thinking, "But what if someone sneaks into your house
> (e.g., no-knock warrant) and performs an Evil Maid attack on you?"
>
> If you have reason to believe that someone might sneak into your house
> (and that you wouldn't notice afterward), then yes, that's a legitimate
> concern for you. However, consider this: If someone can sneak into your
> house, then they can also install a hidden pinhole camera somewhere
> which records your keystrokes (or a hardware keylogger, or something
> else which performs the same function of sniffing your typed passphrases).
>
> "Fine," you say, "then I'll just use my AEM stick to supply a keyfile
> for my LUKS encrypted system drive. This way, even if they somehow learn
> my passphrase, they still won't be able to decrypt my system drive." The
> only problem is that your *backup* doesn't require a keyfile (nor should
> it, since a disaster which requires you to restore from the backup could
> easily destroy all available copies of the keyfile). So, all the
> attacker has to do is learn your backup passphrase and acquire a copy of
> your encrypted backup file (which is probably pretty easy to do without
> your notice if you're storing copies off-site, like you're supposed to).
>
> Does anyone have a solution for this? :)

That's a very good point about backups being vulnerable to keystroke
sniffing attacks. I don't have a convenient solution to that problem,
apart from Being Carefull(TM) while entering your backup passphrase. The
"Being Careful(TM)" should include taking into account not only hidden
cameras, but also EM leaks (e.g. look out for a van with tinted windows
near your house while entering your passphrase ;)

A solution with splitting your backup passphrase to have part of it
being kept on some smartcard buys one little in case the adversary hsa a
warrant on you -- they can just seize your smartcard..

Perhaps a better solution would be to somehow keep the backup passphrase
in a text file in you dom0 and only copy-paste it for the backup, or
even do something like:

qvm-backup --passphrase `cat ~/my_backup_passphrase.txt`

The ~/my_backup_passphrase.txt could be created over a long period of
time, perhaps also using on-screen-keyboard for it (hm, I think KDE in
dom0 doesn't have one, oh well, but it could).

Of course, for this to make sense, one would need to have AEM properly
deployed, your system shut down when you leave your premises, and LUKS
configured to read keyfile from AEM stick (should be easy doable).

joanna.

signature.asc

Joanna Rutkowska

unread,
May 23, 2014, 8:52:22 AM5/23/14
to Axon, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
Hm, after thinking more about this, I think we're essentially faced with
the following dilemma:

1) Do we trust our (still fresh) stick to be "clean" (e.g. because we
just bought it in a shop and just freshly unpacked it),

vs.:

2) Do we trust our usbvm or dispvm to be able to do a good job on
cleaning up a potentially compromised stick

?

If we're reasonably sure we bought a clean stick (case #1), I think we
would be safest to just: 1) stop the usbvm (if we have one), 2) assigned
the usb controller to dom0, 3) insert the stick there and proceed with
normal AEM installation procedure.

If, however, we assume the stick we bought at the shop might be
compromised already (these days it might not be an unreasonable
thinking) then we might want to clean it first. And so the tempatation
is to connect it to a usbvm first, clean it up and install AEM there
before connecting to Dom0. Only that... if it is compromised than, it
might just as well compromised the usbvm the moment we inserted it
there, and so we no longer will be able to clean it up reliably.

So, I think there is really no good workaround against #2 case, is it?

>> Not 100% ideal, but "good enough" IMHO.
>>
>>> 2. The requirement that the Intel SINIT module be copied from an AppVM
>>> to dom0 directly contradicts the Qubes rule that files should never be
>>> copied from AppVMs to dom0 (as well as the more general security rule
>>> that files should never be copied from less trusted to more trusted
>>> security domains). I'm not sure if this one is avoidable (and I did read
>>> the note about this in the doc), but please consider this in conjunction
>>> with point 1 above. According to the AEM docs, the current procedure is
>>> to copy the .BIN from the AppVM to dom0's /boot. Then the whole of /boot
>>> is copied to the AEM stick. Can we instead copy /boot from dom0 to the
>>> stick, then copy the .BIN from the AppVM directly to the stick? Really
>>> anything is better than telling the user to download some weird binary
>>> from the Internet and then copy it to dom0...
>>>
>>
>> Yes, I think so, it should be no problem to copy SINITs as part of step
>> #1 outlined above.
>>
>
> Sorry, I'm not sure what your "yes" is referring to. Is it a yes to the
> question of whether we can just copy the .BIN directly to the stick?

Yes :) Although, as just discussed above, this whole AEM preparation in
AppVM (usbvm or dispvm) really gives you nothing :/

> I must confess I'm also not sure which "step #1" you're referring
> to. (Your step #1 above is just "Create a fresh DispVM," so I assume
> it must be a different "step #1," but I don't see any others "above"
> where you wrote that...).
>
>> The SINIT files are loaded and executed by tboot
>> (processor's SENTER) only if they are properly signed by Intel (at least
>> this is what SDM days). So, this should not be a problem.
>
> Hm, this sounds like you're saying that it should not be a problem to
> copy the SINIT files to dom0 (since they're executed only if properly
> signed), so maybe you weren't answering yes to my question after all...
>

No problem copying a stream of bytes to dom0, as long as they are not
used by anything in dom0 (or used only conditioned on some additional
verification of their signature). In case of SINIT files lying in /boot
on dom0, this is just the case -- these are merely some blobs, which no
software in dom0 ever uses (unless a user explicitly types in dom0
commands in Dom0 to somehow open them, etc). They are only used by tboot
during OS booting, as we trust tboot to be actually verifying them
before using.

At least I'm pretty sure that SENTER verifies the content of those files
before executing it. It is less clear to me if tboot does any
non-trivial processing of the .BIN files in order to extract what's
inside and pipe to SENTER? If so, this code would be the potential
attack point where a malicious SINIT file could potentially exploit.
Anybody care to research this further?

>> Of course we cannot just package SINITs together with AEM rpm(s) because
>> of licensing limitations.
>>
>>> 3. As noted by others, there does not appear to be an option in the AEM
>>> installer to install to disk (rather than to a removable drive). The
>>> installer states that the selected partition will be formatted before
>>> /boot is copied to it, making it impossible (or just a really bad idea)
>>> to select the /boot partition itself as the destination.
>>>
>>
>> IIRC this should work fine:
>>
>> mv /boot /boot.orig
>>
>
> Sorry, I'm not sure I understand. If I do that before selecting the
> partition on which /boot resides, then how will the AEM installer copy
> /boot to the stick?
>

Ah, would "cp -r" instead of "mv" solve this problem? (Sorry, it's been
a while since I installed AEM on a HDD, and cannot test this ATM).
Hm, isn't that most RAID solutions (at least HW/BIOS-based) should be
exposing /dev/sdX device after all? I.e. that nobody should really be
using /dev/mdX? I don't know really...

Thanks,
joanna.

signature.asc

Axon

unread,
May 24, 2014, 3:34:22 AM5/24/14
to Joanna Rutkowska, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
Joanna Rutkowska:
Many of the new, factory-sealed USB flash drives I buy have "stuff" on
them already. Usually it's some crap software put there by the
manufacturer. So I always like to zero-fill them before using them for
my own purposes. And, indeed, this presents exactly the dilemma you
describe. I have often wished there were a very simple device into which
I could plug a USB mass storage device, press a button, and it would
simply write zeros until there's no more room. (In addition to the
single button, there would be a single LED on this device, which would
be lit if and only if the device is writing. Once the light goes off, I
can unplug the drive. The firmware/software of this device would not be
modifiable in any way.) Is something like this possible? Anyway, I think
it would solve our problem. :)

In any case, the manufacturer bloatware (if you can call it that)
pre-written to USB drive is probably more annoying than malicious.
However, nowadays it's probably not unreasonable to fear that a USB
drive which you order online might have been "interdicted" and that
special software might have been added just for you that runs as soon as
you plug in the drive.
OK. :)

> At least I'm pretty sure that SENTER verifies the content of those files
> before executing it. It is less clear to me if tboot does any
> non-trivial processing of the .BIN files in order to extract what's
> inside and pipe to SENTER? If so, this code would be the potential
> attack point where a malicious SINIT file could potentially exploit.
> Anybody care to research this further?
>
>>> Of course we cannot just package SINITs together with AEM rpm(s) because
>>> of licensing limitations.
>>>
>>>> 3. As noted by others, there does not appear to be an option in the AEM
>>>> installer to install to disk (rather than to a removable drive). The
>>>> installer states that the selected partition will be formatted before
>>>> /boot is copied to it, making it impossible (or just a really bad idea)
>>>> to select the /boot partition itself as the destination.
>>>>
>>>
>>> IIRC this should work fine:
>>>
>>> mv /boot /boot.orig
>>>
>>
>> Sorry, I'm not sure I understand. If I do that before selecting the
>> partition on which /boot resides, then how will the AEM installer copy
>> /boot to the stick?
>>
>
> Ah, would "cp -r" instead of "mv" solve this problem? (Sorry, it's been
> a while since I installed AEM on a HDD, and cannot test this ATM).
>

Oh, I see what you mean now. (I haven't tried it, but this clears up my
confusion. Thank you.)
For true hardware raid or BIOS fakeRAID, probably. But when you create
RAID partitions via the Qubes/Fedora installer, they end up as
"/dev/mdX". (This is effectively the same as using mdadm.) Consensus in
the Linux community seems to be that software RAID is superior (unless
you have a really expensive true hardware RAID controller).

> Thanks,
> joanna.
>


signature.asc

Axon

unread,
May 24, 2014, 3:37:52 AM5/24/14
to Joanna Rutkowska, cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
Joanna Rutkowska:
Yes, I was thinking about this too. The only problem is that using an
on-screen keyboard doesn't help if your adversary has a hidden camera in
place already, since the camera can see on-screen keyboard inputs as
easily as (if not more easily than) physical keyboard inputs.

Of course, if you create my_backup_passphrase.txt *before* your
adversary has a hidden camera in place, then you're safe. But the whole
point of hidden pinhole cameras (and other hidden surveillance devices)
is that you can't tell whether they're there (at least not without
expensive specialized scanning equipment and/or lots of time). This, of
course, also applies to all other passphrase-sniffing methods. If you
create my_backup_passphrase.txt before your adversary has a chance to
install a hardware keylogger, then you're just as fine if you just use
the physical keyboard.

So, I suppose you can reduce your risk by only copy/pasting the backup
passphrase each time instead of typing it, but this assumes that you're
safe the first time you enter it, which may or may not be a valid
assumption.

Would it be difficult to add a "remember passphrase" option to the Qubes
backup system? That would be a bit cleaner than copy/pasting from a text
file and serve the same function, I think. Also, the passphrase would be
masked while initially entering it, and there would be no risk of
accidentally unmasking it (as in the case of accidentally opening or
cat-ing my_backup_passphrase.txt).

Another thing to note is that this means that the main system disk
encryption passphrase should be different from the backup passphrase.

> Of course, for this to make sense, one would need to have AEM properly
> deployed, your system shut down when you leave your premises, and LUKS
> configured to read keyfile from AEM stick (should be easy doable).
>

Right. Somewhat related: If someone is *not* using AEM, then would it
actually be safer to leave the system powered on while away? Of course,
this leaves one vulnerable to cold boot attacks, but it seems like cold
boot attacks are actually much harder to pull off in practice than evil
maid attacks. And most intruders (whether robbers or law enforcement
agents) seem more likely to just rip all the cords out of the wall and
haul the hardware away (unless you are some sort of special high-value
target, perhaps).

> joanna.
>


signature.asc

Hakisho Nukama

unread,
May 24, 2014, 7:59:24 AM5/24/14
to Axon, Joanna Rutkowska, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
I would be more concerned about the software, that resides inside
the micro-controller of such devices.
Zeroing out your drive wouldn't buy you an advantage, if the micro-controller
includes some adversary-friendly modification.

http://www.bunniestudios.com/blog/?p=3554

Joanna Rutkowska

unread,
May 24, 2014, 4:53:58 PM5/24/14
to Hakisho Nukama, Axon, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
We need an open source USB stick, perhaps even optimized to act as Anti
Evil Maid stick (TBD). Surely doable using some Arduino boards (e.g.
Leonardo?). Only I'm not sure about how to implement mass storage for it
in a simple way (and not using a 3rd party USB or SD stick). Using
ATMega's flash/eeprom would give us only a few tens of KBs, sadly not
enough for AEM, which needs at least a few hundred of MBs.

Hmm, actually even if we used an Arduino that uses a 3rd party (off the
shelf) USB stick for mass storage and so just acts as a "proxy" for it,
it should actually be quite a safe setup, as we will be controlling the
USB stick's firmware that talks directly to our computer (so no
malicious attacks here). The Arduino might also be implementing a simple
crypto so that the 3rd party stick were also unable to meaningfully
modify the actual content exposed to our computer (e.g. expose malformed
partition table or filesystem metadata). Not sure about the performance
of this "simple crypto" on an 8-bit ATMega. But then, on the other hand,
it's just a few boot modules that we need to read from the stick (mbr,
grub, xen.gz, kernel and initramfs).

Anybody interested? :)

joanna.

signature.asc

Joanna Rutkowska

unread,
May 25, 2014, 5:37:55 AM5/25/14
to Axon, cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
There is always a point where one needs to be safe "for the first
time"... In case of resisting camera -- that's relatively simple to put
on some "hood" around you and the laptop and enter it securely for the
first time :)

The bigger problem I would be afraid of was the EM-sniffing van next to
your apartment. Ok, then you could use a metal-sheet-hood.

> Would it be difficult to add a "remember passphrase" option to the Qubes
> backup system? That would be a bit cleaner than copy/pasting from a text
> file and serve the same function, I think. Also, the passphrase would be
> masked while initially entering it, and there would be no risk of
> accidentally unmasking it (as in the case of accidentally opening or
> cat-ing my_backup_passphrase.txt).
>

I think that should be fine.

> Another thing to note is that this means that the main system disk
> encryption passphrase should be different from the backup passphrase.
>

Yes.

>> Of course, for this to make sense, one would need to have AEM properly
>> deployed, your system shut down when you leave your premises, and LUKS
>> configured to read keyfile from AEM stick (should be easy doable).
>>
>
> Right. Somewhat related: If someone is *not* using AEM, then would it
> actually be safer to leave the system powered on while away? Of course,
> this leaves one vulnerable to cold boot attacks, but it seems like cold
> boot attacks are actually much harder to pull off in practice than evil
> maid attacks. And most intruders (whether robbers or law enforcement
> agents) seem more likely to just rip all the cords out of the wall and
> haul the hardware away (unless you are some sort of special high-value
> target, perhaps).
>

Yes, indeed. Although one should make sure that hot-pluggable devices
are not assigned to Dom0, or at least the modules for hotpluggable
bridges are not loaded (I think this is just enough to deactive
PCMCIA-based hotplug DMA attacks).

joanna.

signature.asc

Robert Fisk

unread,
Jan 31, 2015, 10:39:43 PM1/31/15
to qubes...@googlegroups.com


On 25/05/14 08:53, Joanna Rutkowska wrote:
> On 05/24/14 13:59, Hakisho Nukama wrote:
>>>> Hm, after thinking more about this, I think we're essentially faced with
>>>>>> the following dilemma:
>>>>>>
>>>>>> 1) Do we trust our (still fresh) stick to be "clean" (e.g. because we
>>>>>> just bought it in a shop and just freshly unpacked it),
>>>>>>
>>>>>> vs.:
>>>>>>
>>>>>> 2) Do we trust our usbvm or dispvm to be able to do a good job on
>>>>>> cleaning up a potentially compromised stick
>>>>>>

<snip>

>
> We need an open source USB stick, perhaps even optimized to act as Anti
> Evil Maid stick (TBD). Surely doable using some Arduino boards (e.g.
> Leonardo?). Only I'm not sure about how to implement mass storage for it
> in a simple way (and not using a 3rd party USB or SD stick). Using
> ATMega's flash/eeprom would give us only a few tens of KBs, sadly not
> enough for AEM, which needs at least a few hundred of MBs.
>
> Hmm, actually even if we used an Arduino that uses a 3rd party (off the
> shelf) USB stick for mass storage and so just acts as a "proxy" for it,
> it should actually be quite a safe setup, as we will be controlling the
> USB stick's firmware that talks directly to our computer (so no
> malicious attacks here). The Arduino might also be implementing a simple
> crypto so that the 3rd party stick were also unable to meaningfully
> modify the actual content exposed to our computer (e.g. expose malformed
> partition table or filesystem metadata). Not sure about the performance
> of this "simple crypto" on an 8-bit ATMega. But then, on the other hand,
> it's just a few boot modules that we need to read from the stick (mbr,
> grub, xen.gz, kernel and initramfs).
>
> Anybody interested? :)
>
> joanna.
>


Hi all,

This thread stuck in my mind last year, and having spent some time on
research I would like to re-animate it.

On the topic of taming BadUSB, I can envision a hardware widget that
contains two microcontrollers. One talks to the PC and emulates a USB
device, such as a flash drive (mass storage class). The other
microcontroller is a USB host talking to the actual untrusted flash
drive. The two microcontrollers pass data through a simple protocol over
a local bus such as SPI at ~10MHz.

Any attempt by the untrusted USB device to exploit the host stack cannot
break out of the first microcontroller due to the restricted protocol on
the local link. Any attempt to act as a composite device with keyboard
and thereby insert malicious keystrokes into the host PC will fail
because the microcontroller firmware cannot support both a flash drive
and a keyboard at the same time.

The hardware required for this widget will probably involve a couple of
development boards from Olimex. One has the device connector onboard,
while the other has the host connector. Some assembly of the inter-board
link will be required.

https://www.olimex.com/Products/ARM/ST/STM32-H405/
https://www.olimex.com/Products/ARM/ST/STM32-H407/

The STM32 processors on these boards are well-supported by opensource
development tools, and support a (relatively) easy upgrade path to USB2
with the addition of external PHYs. They also have enough horsepower to
perform simple encryption to obfuscate the data written to the flash drive.

This approach can be extended to isolate other USB devices, eg keyboards
and mice, and potentially 3G modems through the CDC device class. It
will also be possible to integrate the entire design onto a single PCB,
although that will be left as an exercise for the future.

This project will of course be of interest to users of all OSs. But I am
asking for input here to guide the project so that it may be more useful
to the paranoid group known as Qubes users! Any comments welcome.

Regards,
Robert



coderman

unread,
Jan 31, 2015, 10:43:49 PM1/31/15
to Robert Fisk, qubes...@googlegroups.com
On 1/31/15, Robert Fisk <rober...@fastmail.fm> wrote:
> ...
> The hardware required for this widget will probably involve a couple of
> development boards from Olimex. One has the device connector onboard,
> while the other has the host connector. Some assembly of the inter-board
> link will be required.
>
> https://www.olimex.com/Products/ARM/ST/STM32-H405/
> https://www.olimex.com/Products/ARM/ST/STM32-H407/

interesting - i am currently waiting on delivery of USB Armory
devices; the cost is a premium, but a pair back to back could achieve
this technique:
https://www.crowdsupply.com/inverse-path/usb-armory

fun in either case; please report results here, too. good luck!


best regards,

David Hobach

unread,
Aug 30, 2015, 8:17:27 AM8/30/15
to jonbrown...@gmail.com, qubes-devel
On 08/30/2015 07:03 AM, jonbrown...@gmail.com wrote:
> I think you guys will find this might be exactly what you want. Here is
> a USB MiTM Proxy system that utilizes the Beagle Board Black.
>
> https://dominicspill.com/presentations/2014/Spill_BSidesLV_USBProxy_slides.pdf
> https://www.youtube.com/watch?v=5JnAeakUBnU
> https://www.youtube.com/watch?v=IQpPgnU-O-A
>
> If anyone finds a way to use this to help secure their system please
> share it. :)

Had a short look and it appears to be about making a USB medium read-only?

For mass storage it's much more simple to buy a USB stick with read-only
switch for that. Nowadays there's even one's with hardware encryption
and keyboard on the stick out there.

AEM however also checks the BIOS integrity (if it works) and you cannot
get that feature with such gadgets. If BIOSes were read-only maybe then
it would be a better solution over AEM.

> On Monday, February 24, 2014 at 11:26:14 AM UTC-6, David Hobach wrote:
>
> Dear developers,
>
> Let me first explain my setup:
> Dual boot (latest Qubes with all patches + Windows for gaming) desktop
> machine --> AEM seemed a reasonable choice for me. As it is a desktop
> machine, I didn't want to go for the USB stick solution, but rather use
> another password to unseal the TPM. AEM was meant to be installed to
> the
> /boot partition.
>
> During the AEM installation I discovered the following two bugs:
>
> 1. The AEM installer doesn't support a direct installation to /boot as
> needed for my setup (and as indicated by the README). After reading
> through the installer script I noticed I didn't want to re-format my
> /boot partition... I managed to get around this problem though.
>
> 2. The tpm_unsealdata during boot doesn't work if a password is
> specified for TPM operations.
> Reason: It doesn't have access to stdin to read the password as
> a) The service is not configured to have access to stdin (explicitly
> set
> to "null" in the config).
> b) Reading from stdin during the boot process seems to be a lot
> different than reading from it during normal OS runtime. stdin seems to
> be managed by plymouth and/or systemd depending on whether plymouth is
> used or not. Therefore commands reading from stdin during the boot
> process are usually wrapped inside other functions to accomplish the
> plymouth/systemd hassle. This is e.g. done that way for the cryptsetup
> operations.
>
> I fixed 2. a) + b) for my setup (I didn't test others). You can find
> the
> patched files attached.
>
> My kernel parameters fyi:
> GRUB_CMDLINE_LINUX="rd.md <http://rd.md>=0 rd.dm <http://rd.dm>=0
> rd.luks.uuid=luks-184b810f-55df-4198-ae45-07843a9699b4 $([ -x
> /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param ||
> vconsole.keymap=de rd.lvm.lv <http://rd.lvm.lv>=qubes_dom0/root
> rd.antievilmaid.asksrkpass
> rd.antievilmaid.dontforcestickremoval plymouth.enable=0"
>
> Thanks for your good work at Qubes!
>
> Kind Regards
> David
>

jonbrown...@gmail.com

unread,
Aug 30, 2015, 8:47:42 AM8/30/15
to qubes-devel, tri...@hackingthe.net
I think you guys will find this might be exactly what you want. Here is a USB MiTM Proxy system that utilizes the Beagle Board Black.


If anyone finds a way to use this to help secure their system please share it. :)
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0
rd.luks.uuid=luks-184b810f-55df-4198-ae45-07843a9699b4 $([ -x
/usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param ||
vconsole.keymap=de rd.lvm.lv=qubes_dom0/root rd.antievilmaid.asksrkpass

jonbrown...@gmail.com

unread,
Oct 11, 2017, 4:25:27 PM10/11/17
to qubes-devel
Hey guys and girls,

I have just saw an impressive talk on YouTube Matthew Garrett: Beyond Anti Evil Maid. I was wondering if any of this could/should be considered to potentially improve the current AntiEvilMaid system. If possible I would love one of you pros to check this out and see if it could provide some value.

Here is the link to the video: https://www.youtube.com/watch?v=ykG8TGZcfT8


Reply all
Reply to author
Forward
0 new messages