Timezone and other deanonymizing data in QubesDB

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

There are some QubesDB entries which could break (or at least lower) user
anonymity in AnonVM in case of VM compromise. I think you better know
which ones. There is an idea of introducing some setting in dom0, which
would prevent such setting from being exposed, but I'm thinking of some
other option: dom0 set those entries at VM startup and do not update
them later, VM is free to alter or even remove any QubesDB entry. So
VM can replace or even remove all such entries early in startup scripts,
even before /rw is mounted.

This have huge advantage: simplicity of implementation. The only
downside I see here it will only work assuming Whonix-workstation
template isn't compromised. What threat model are we aiming for here?

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWAvpoAAoJENuP0xzK19cs0lEIAJsk+6qXFjCRo4YiEJgDhVj4
eabUJ1DRu5yoo/WXIifWTaePFouZI89CT5YevPVNQKxju4Yf3tIiMy9JlLga2w95
XJ+bz8K2yPv19JbBV+Qc+iClZgpW9MOBKUUsaFl5KJ+IfeQnYq5Ax29AJ/7Bm1W8
5K4/fVxwisqvxpeW5joAt2LDWCc9iRRwb6G65u5qIZ5gbJiBURqC3gsxmHE0o/RW
8D5qrmqwWPhFhWHZj0Dw9VKQrvdor66DL8p66nwDdwz7S3sei1416JqydNM/we1V
eFuwA568otDnsYS/97zLjjXJYxMeIPQIXthMN0TNCPxW+OQ8WzEKQ7X5UGL4Yew=
=e2YS
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Awesome stuff!

Marek Marczykowski-Górecki:

> There are some QubesDB entries which could break (or at least lower) user
> anonymity in AnonVM in case of VM compromise. I think you better know
> which ones.

Anyone please check those!

run:
qubesdb-list /

Problematic ones:

- qubes-keyboard:
Would be better to hide. Although I guess that would be difficult
implementation wise? I don't know how Qubes keyboard implementation
works. It would be desirable if it was possible to leave the VM thinking
"standard US layout", while the user can use its native layout which is
only known to dom0.

- qubes-timezone:
Definitively hide.

- qubes-usb-devices:
Potentially. Empty for me. What does it contain and when?

> There is an idea of introducing some setting in dom0, which
> would prevent such setting from being exposed, but I'm thinking of some
> other option: dom0 set those entries at VM startup and do not update
> them later, VM is free to alter or even remove any QubesDB entry. So
> VM can replace or even remove all such entries early in startup scripts,
> even before /rw is mounted.
>
> This have huge advantage: simplicity of implementation.

Yes, the latter implementation is to be preferred.

> The only
> downside I see here it will only work assuming Whonix-workstation
> template isn't compromised.

Yes.

> What threat model are we aiming for here?

In a compromised Whonix-Workstation it would be useful to hide timezone
information as this allows anonymity set reduction.

Therefore, do you think it would be possible for an AppVM to remove any
QubesDB entry permanently?

qubesdb-rm --permanent qubes-timezone

This could be done at first boot of the AppVM (while its still
considered clean). If it could not be recovered at any subsequent boots,
that implementation would be perfect from Whonix-inside-VM perspective.

Cheers,
Patrick

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Sep 23, 2015 at 07:59:30PM +0000, Patrick Schleizer wrote:
> Awesome stuff!
>
> Marek Marczykowski-Górecki:
> > There are some QubesDB entries which could break (or at least lower) user
> > anonymity in AnonVM in case of VM compromise. I think you better know
> > which ones.
>
> Anyone please check those!
>
> run:
> qubesdb-list /

qubesdb-multiread /
:)

My output:
[user@testvm tmp]$ qubesdb-multiread /
name = testvm
qubes-base-template = fedora-21
qubes-block-devices =
qubes-debug-mode = 1
qubes-gateway = 10.137.1.1
qubes-ip = 10.137.1.45
qubes-keyboard = xkb_keymap {\x0a\x09xkb_keycodes { include
"evdev+aliases(qwerty)"\x09};\x0a\x09xkb_types { include
"complete"\x09};\x0a\x09xkb_compat { include
"complete"\x09};\x0a\x09xkb_symbols { include
"pc+pl+inet(evdev)"\x09};\x0a\x09xkb_geometry { include
"pc(pc104)"\x09};\x0a};
qubes-netmask = 255.255.255.0
qubes-secondary-dns = 10.137.1.254
qubes-service/meminfo-writer = 1
qubes-service/qubes-update-check = 0
qubes-timezone = Europe/Warsaw
qubes-usb-devices =
qubes-vm-persistence = rw-only
qubes-vm-type = AppVM
qubes-vm-updateable = False

>
> Problematic ones:
>
> - qubes-keyboard:
> Would be better to hide. Although I guess that would be difficult
> implementation wise? I don't know how Qubes keyboard implementation
> works. It would be desirable if it was possible to leave the VM thinking
> "standard US layout", while the user can use its native layout which is
> only known to dom0.

GUI protocol uses keycodes, so when user uses significantly different
layout, it wont work. More precisely - it will work as it would be US
layout. Maybe not a big problem? User is free to change keyboard layout
manually inside of VM (using setxkbmap or any GUI equivalent).

> - qubes-timezone:
> Definitively hide.
>
> - qubes-usb-devices:
> Potentially. Empty for me. What does it contain and when?

This is place where VM can expose what devices are connected to this VM
(mostly useful for USB VM). Dom0 doesn't set anything here. Similar for
qubes-block-devices.

> > There is an idea of introducing some setting in dom0, which
> > would prevent such setting from being exposed, but I'm thinking of some
> > other option: dom0 set those entries at VM startup and do not update
> > them later, VM is free to alter or even remove any QubesDB entry. So
> > VM can replace or even remove all such entries early in startup scripts,
> > even before /rw is mounted.
> >
> > This have huge advantage: simplicity of implementation.
>
> Yes, the latter implementation is to be preferred.
>
> > The only
> > downside I see here it will only work assuming Whonix-workstation
> > template isn't compromised.
>
> Yes.
>
> > What threat model are we aiming for here?
>
> In a compromised Whonix-Workstation it would be useful to hide timezone
> information as this allows anonymity set reduction.
>
> Therefore, do you think it would be possible for an AppVM to remove any
> QubesDB entry permanently?
>
> qubesdb-rm --permanent qubes-timezone
>
> This could be done at first boot of the AppVM (while its still
> considered clean). If it could not be recovered at any subsequent boots,
> that implementation would be perfect from Whonix-inside-VM perspective.

QubesDB content is recreated on each VM startup, and the state is
destroyed at VM shutdown, so not easily possible. If we want dom0 to not
provide those settings at all, it needs to be done as some VM property.

Then to ease configuration we may introduce some simple qrexec service
which will allow a VM to one way switch such property.
Similar approach is used currently for Windows VMs -
Qubes Windows Tools calls qubes.NotifyTools service in dom0, which
update qrexec_installed and guiagent_installed properties on that VM -
so on the next startup it can use integration tools like secure
clipboard, file copy etc.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWAwnrAAoJENuP0xzK19csI9wH/jIuf5G/ZhIU5/KYgx1ofiLL
HSHH0e0aVSb1C7t1GhexZNyO3lTt6s1cXwNf0jaT9O557vrkkbI/KzyDDkkLUQjz
AUOpxHAY26/4rSG/dkfEgsQ6w2uH5anEyI80dDUYN1yYk0wLGWdU314ZTvNLAlQy
3nuWsVyt7ja3ujWtl87dL5CAUylfECfJtv6Qdgks32F9AOD945znvA4UDx6rsSsL
U9HboNLEwvtYj6d1oSwVilrz91IVb24wa5JTOSjs+zxIFpRNvjjS/vakGf7uFLii
JUN4wjucPI4or2r5nh9hM0aVVMS0LTZkRRtzXxV67YiZ5h5u46ddlSYiGaX22Bo=
=Zcjr
-----END PGP SIGNATURE-----

[cprise]

name = untrusted
qubes-base-template = debian-8-desktop
qubes-block-devices =
qubes-debug-mode = 0
qubes-gateway = 10.137.3.1
qubes-ip = 10.137.3.8

qubes-keyboard = xkb_keymap {\x0a\x09xkb_keycodes { include
"evdev+aliases(qwerty)"\x09};\x0a\x09xkb_types { include
"complete"\x09};\x0a\x09xkb_compat { include
"complete"\x09};\x0a\x09xkb_symbols { include

"pc+us(colemak)+inet(evdev)+shift(both_capslock_cancel)"\x09};\x0a\x09xkb_geometry
{ include "pc(pc101)"\x09};\x0a};
qubes-netmask = 255.255.255.0
qubes-secondary-dns = 10.137.3.254
qubes-service/meminfo-writer = 1
qubes-timezone = America/New_York

qubes-usb-devices =
qubes-vm-persistence = rw-only
qubes-vm-type = AppVM
qubes-vm-updateable = False

>
>>
>> Problematic ones:
>>
>> - qubes-keyboard:
>> Would be better to hide. Although I guess that would be difficult
>> implementation wise? I don't know how Qubes keyboard implementation
>> works. It would be desirable if it was possible to leave the VM thinking
>> "standard US layout", while the user can use its native layout which is
>> only known to dom0.
>
> GUI protocol uses keycodes, so when user uses significantly different
> layout, it wont work. More precisely - it will work as it would be US
> layout. Maybe not a big problem? User is free to change keyboard layout
> manually inside of VM (using setxkbmap or any GUI equivalent).

Open an issue for this?

Unfortunately, Qwerty has to be the worst layout in the world. Sticking
out like a sore thumb online because you use something better (and can't
type Qwerty) is a big issue, I think. Some people also live in regions
that use layouts with a small demographic. The VMs already scream "I'm a
Qubes user"; More than that is just TMI.

I wouldn't see the ability to change layout inside a VM as a plus
anyway; Having Qubes handle the layout completely in dom0 would be best.

[Patrick Schleizer]

Marek Marczykowski-Górecki:

> On Wed, Sep 23, 2015 at 07:59:30PM +0000, Patrick Schleizer wrote:
>> - qubes-keyboard:
>> Would be better to hide. Although I guess that would be difficult
>> implementation wise? I don't know how Qubes keyboard implementation
>> works. It would be desirable if it was possible to leave the VM thinking
>> "standard US layout", while the user can use its native layout which is
>> only known to dom0.
>
> GUI protocol uses keycodes, so when user uses significantly different
> layout, it wont work. More precisely - it will work as it would be US
> layout. Maybe not a big problem? User is free to change keyboard layout
> manually inside of VM (using setxkbmap or any GUI equivalent).

Having the user manually set the layout in the VM is a usability issue.

Defaulting the VM to querty for better security while the user has
really qwertz or so, hoping some will keep querty in the VM for better
security seems sadomasochistic. Users will ask how to set to their
native keyboard layout. And not having this already done by dom0 is a
security issue.

What I am asking for here is probably too much magic? A mapping feature.
Example:
- real keyboard: qwertz
- dom0 keyboard setting: querz
- (all) VMs: internally think they are using the default querty
- now, Qubes/Xen maps these keys. Translates qwertz to VM's querty.

But anyhow. Even with such a mapping feature. It would only slow down
simplistic adversaries. Typing on specific layouts produces subtle
differences in typing speed. Measurable. Fingerprintable.

Some more info:
https://trac.torproject.org/projects/tor/ticket/2876

I think it's safe to assume that machines can guess which hardware
keyboard layout is really used with very high certainty.

Effectively hiding the keyboard layout would require to delay the
keyboard presses to the the AppVM.

But even then, for example quertz users are more likely to mistype
sometimes a 'z' if they wanted to press 't' due to the closer physical
proximity of the keys.

So really hiding the keyboard layout from the VM is actually a hard problem.

Sounds good!

Cheers,
Patrick

[Patrick Schleizer]

Patrick Schleizer:

> So really hiding the keyboard layout from the VM is actually a hard problem.

Having explained that, the short summary of what I wanted to say is for
the purpose of this thread, wrt to keyboard layout is

"Hiding 'qubesdb-read /qubes-keyboard' from the VM or changing the
current Qubes keyboard implementation the the goal of this thread is
probably not worth it at this point."

Cheers,
Patrick

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> Hi,
>
> There are some QubesDB entries which could break (or at least
> lower) user anonymity in AnonVM in case of VM compromise. I think
> you better know which ones. There is an idea of introducing some
> setting in dom0, which would prevent such setting from being
> exposed, but I'm thinking of some other option: dom0 set those
> entries at VM startup and do not update them later, VM is free to
> alter or even remove any QubesDB entry. So VM can replace or even
> remove all such entries early in startup scripts, even before /rw
> is mounted.
>
> This have huge advantage: simplicity of implementation. The only
> downside I see here it will only work assuming Whonix-workstation
> template isn't compromised. What threat model are we aiming for
> here?
>
>

$ qubesdb-list /
bash: qubesdb-list: command not found...

$ qubesdb-multiread /
bash: qubesdb-multiread: command not found...

I'm guessing this is only on R3.x?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWA8EyAAoJEJh4Btx1RPV8i1AP/37aYv8j2Ms5a7jsZulyqMcM
mXzvBu0PkKjNlGZ2qVATVI9JTpbRiJNVuYxHQEcZg+hgTdKcMM1hJ4SNkCulyKXD
WzIbaFqd0IyKo3mkEPIEKKqCnBBA0vJk5dL1nY0ANfYMuWNGcnHYiXaJZYT9aM41
cCnI2K2aD+cRRAwRJ2U3HETxO8pZ5mzeDM8Yj8TAvfzyw7NpvXpBwndVaaclt/YN
xkvriPN5f7iU7j8FM6RC824sNlMDEw23Fwi0i8ie3t8w432znQrZLPjUHBTK01ln
A0TYYssYPRsKuW9AR1RMLBpKv2Czfej+bFJdjSiixoUxrKnGI3V9VIZu/EGKwmo4
OuGxxpQUubfxE96rV3uqztNv6e2SXe6hNai2luhkeGCJPwVJQq5o4bBG3e6ut1lr
lG375KQ80u8v3134noBw0j/RU+bP6XGqQmYxfZ7O5QUc+AhQOSED9rL3bdb/QZdG
zVqYQW4TXBoqHbyGQ4ZmHI+1uh1U1JaLrfTjMmbUrLNGqz9G8hOnlQRLe23CFQ+W
rn4nm8d75C3+IUJdZDK0edqUUIt99VmxiSdBJn6CmTzdhbxOVSxjg0S9ahXyJF/g
iZlNYRKJXnOR+JLP/DqqebHF3JhBG4bT2KGgath52mO6sBlaS2jpV31hrV4KgzR4
QGczJFnM2MNgovHfWSud
=SYJj
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Sep 24, 2015 at 09:24:08AM +0000, Axon wrote:
> Marek Marczykowski-Górecki:
> > Hi,
> >
> > There are some QubesDB entries which could break (or at least
> > lower) user anonymity in AnonVM in case of VM compromise. I think
> > you better know which ones. There is an idea of introducing some
> > setting in dom0, which would prevent such setting from being
> > exposed, but I'm thinking of some other option: dom0 set those
> > entries at VM startup and do not update them later, VM is free to
> > alter or even remove any QubesDB entry. So VM can replace or even
> > remove all such entries early in startup scripts, even before /rw
> > is mounted.
> >
> > This have huge advantage: simplicity of implementation. The only
> > downside I see here it will only work assuming Whonix-workstation
> > template isn't compromised. What threat model are we aiming for
> > here?
> >
> >
>
> $ qubesdb-list /
> bash: qubesdb-list: command not found...
>
> $ qubesdb-multiread /
> bash: qubesdb-multiread: command not found...
>
> I'm guessing this is only on R3.x?

Yes. On R2 we have similar entries in xenstore, but there is no easy way
to list them from within a VM. You can list them from dom0:
xenstore-ls /local/domain/`xl domid VMNAME`

Besides Qubes specific entries, there is also Xen devices configuration.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWA+/gAAoJENuP0xzK19csrTkH/icacTVSsim+2+7yTajBGbRr
uzGDIvfddbdHEUsImUCiT/pimLX91Xl3K/6H791O/MtWgfX2XEDs4Tw3rBN0pwRg
AOHpTSGwI7pjiZ0bIhS9jw1cYjPp6fBMk7WcuyoXCKgpXAnQ2X180+L4qy5xfNeX
dzHR5wfNPj5FxLz/j8rTJtx4KCS8uzVhG3wJHHgbXg4TYOCvFxvZN1TPPpiQgHFc
V8z67vjWCAf/CBL8O0VDB8RAnlVRgHUnA/x1/vq53l1eskB8iE66TCfycpJZAS8n
nwqWhtPtENWpqroAvRnqyQ2J6FFobiQyAfNHIKCuHu5Roc60OQkOx74x6Nbdpro=
=eLWO
-----END PGP SIGNATURE-----

[Vít Šesták]

Hello,
I see two potential issues of that approach:

1. I am not sure if it will make the implementation simpler. How would be StandaloneVMs supported? I am afraid that supporting StandaloneVMs implies implementing another approach.

2. I am not sure, but it might be hard to ensure that the data does not remain in any later memory dump. Note that Linux kernel does not clear the memory when a process exits. Just reading some sensitive data might cause their presence in some future memory dump even if the process exits.

Sure, #2 can be somehow prevented. I am just saying that the design is error-prone in this way and even some future modification might open a deanonymization vulnerability.

Regards,
Vít Šesták 'v6ak'

[Vít Šesták]

Hello,

On Thursday, September 24, 2015 at 1:10:52 AM UTC+2, Patrick Schleizer wrote:

What I am asking for here is probably too much magic? A mapping feature.
Example:
- real keyboard: qwertz
- dom0 keyboard setting: querz
- (all) VMs: internally think they are using the default querty
- now, Qubes/Xen maps these keys. Translates qwertz to VM's querty.

Such mapping is either not so simple or very limited. How would you map umlauts and other non-English characters to us-qwerty? Characters like “ü”, “ú”, “š” and so on cannot be directly mapped to us qwerty. We would have to make some Qubes special layout or use something like Ctrl+Shift+U;hexacode;enter. This, however, does not solve some other issues:
* some keys can be used for keyboard shortcuts
* some symbols can be result of multiple keys pressed simultaneously. For example AltGr+V on Czech keyboard is „@“, which can be translated to Shift+2 (the 2 key above top row, not the 2 key on numpad). But what to do with the AltGr keypress?
* similar issues with dead keys

To sum it, it might be possible to implement is, but it would not be so easy to implement. It would probably bring some issues, even if some high effort is taken. It would be probably impossible to implement it perfectly.

And even if you do, there are some side channel in typing speed, as you say. There would be also some side channels in typos (e.g. if you type „U“ instead of „Y“, you are likely to use QWERTY and not QWERTZ).

While automatically setting the keyboard in standard VMs is good, I believe that using some default (e.g. us-qwerty) layout and letting user to handle it itself is the right approach for high-anonymity VMs.

Regards,
Vít Šesták 'v6ak'

[Vít Šesták]

One more note: A VM can guess other VM names through sending some requests to them. In some special cases, this could help with deanonymization. And I don't think this can be completely prevented from a VM that is compromised in some future.

Regards,
Vít Šesták 'v6ak'