Application Customization and Privacy Issues

Support
1

Continuing the discussion from Qubes DispVM technical discussion:

This post has a Qubes feel to it because it was originally to be posted in Qubes-Whonix sub-forum. Halfway through though, I realized it was applicable to all Whonix flavors. The concept of Template VMs are universal, just called different things, ie base images. In short, separate VMs are not enough to guarantee identity isolation if customization parameters are shared by those VMs and are discoverable.

Hereā€™s my draft:

It is strongly recommended to never run user applications (especially network-facing ones) in any type of template VM. This is because applications often generate files, that when propagated to child VMs, can result in VM-linkability. For example, starting Firefox and connecting to a website might result in the download of unique cookies. Some applications may generate a random number seed that could be used to identify the VM uniquely.

In the case of Tor Browser, an exception may be made to allow for customization. However, it should be clearly understood that the best practice, as recommended by The Tor Project, is to use Tor Browser in its stock configuration. This is because Tor Browser has a very deliberate fingerprint, one that is designed to be shared by all Tor Browser users. Even seemingly innocuous changes, like enabling the NoScript option to ā€˜Show message about blocked scriptsā€™ can alter the fingerprint by changing the reported screen size. Further, while Tor Browser is designed to prevent any type of linkability through fingerprinting, issues past and present suggest that it is not perfect. These issues are only magnified by using a custom configuration that is shared by multiple VMs.

But after re-reading the original text, I changed my mind. Hereā€™s a very relevant ticket to our situation: Browser configuration fingerprinting (#14390) Ā· Issues Ā· Legacy / Trac Ā· GitLab. This bug is still embargoed after 2 years?!?!? Given something like that, how can we recommend anything other than best practice / stock configuration? In fact, I think we need to do the opposite and whitelist things that are safe to customize in templates for Tor Browser.

  • Can you customize the toolbar? Add/remove buttons?
  • Can you change Preferences?
    -tab behavior?
    -download directory?
    -search engines?
    -update preferences? (I find it very useful for disposableVMs to set update to notify-only instead of auto)
  • NoScript? disable JS?
  • TorButton? change security slider?

What about other applications? Iā€™m sure most users have a favorite terminal and a set of preferences for it. Even if you donā€™t customize a terminal in your template VM, if you then perform the identical customization in each of your user VMs, the result will be the same. An adversary that gains user-access to your VMs will be able to link them together based solely on your config files.

With Qubes, we rely on the fact that attackers with user/root privileges donā€™t necessarily constitute an existential threat. From a privacy perspective, it could be game over. So do we need to construct a list of customizable apps? or just tell everyone to live in misery with all default settings?

1 Like
2

Iā€™ll answer your non-TBB related questions in my next post.

Use security slider for that.

That should be okay with TBB upstream since they are the ones providing that feature.

Gotta be careful about enabling the menu bar. Could change the screen size (resolution) that websites can detect. Needs testing. Source:

That ticket is now called a duplicate, but I wonder if the issue is 100% solved. There is also a lack of testing tools.

Thatā€™s also a good question for the Tor support channels. I am not aware of any guide that mentions these topics.

Also your not mentioned other questions about Tor Browser customizations demand canonical answers by the official TBB support.

3
  • Non-Qubes-Whonix: applies when using one VM as template and then making a clone
  • Qubes-Whonix: applies since most users are using TemplateVMs and TemplateBased AppVMs

You may not even need to customize applications settings. There is a ton of other such unique things. Small incomplete list of examples:

  • The template contains filesystem timestamp information. These differ.
  • /var/lib/systemd/random-seed
  • /var/cache/ldconfig/aux-cache
  • /var/lib/dpkg/info/man-db
  • /var/lib/dpkg/info/docbook-xsl
  • /var/lib/dpkg/info/sgml-data
  • /var/lib/dpkg/info/xml-core
  • /usr/share/info/dir
  • /usr/lib/pymodules/python2.7/**/init.pyc
  • logs - what wins to write first, cron or apt-get - hard to make deterministic since it depends on so many factors such as cpu and network speed
  • list goes on and on and on
  • I these list from my previous work on verifiable builds. Something much simpler, since that VM image was build in chroot. Never booted and thereby prevented a lot of differences.
  • Yes, Debian works on reproducible package repositories (packages build and ready to be downloaded) and one can only applaud them. Itā€™s still a very long way to go. They also like to create deterministic Debian installer medium, which will be harder, since then packages need to leave deterministic results when installed inside chroot. Having the image staying deterministic when you actually boot it and shut down, I am not sure we ever get there.

Two computers a) and b).

  • Both download a VM (letā€™s say the same Whonix flavor/version) and install it.
  • Start the VM that is supposed to act as template on both computers.
  • Update it.
  • Shut it down.
  • They will differ.
  • In other words they will not have the same checksum. Boot and shutdown will not be a deterministic process.

Even if not user customized any settings in applications, these disk images are still distinguishable for someone who has local disk access. And local disk access is included in the capabilities of an adversary that reached local VM compromise of a template based VM.

  • template VM A
  • template based VM B
  • template based VM C

An adversary that reached local disk access in VM B as well as VM C may likely be able to correlate those to the same pseudonym.

I am not sure if that is enough to advice against using templates for this very reason. There may be other reasons. An adversary who merely runs a website, that could link VM B and VM C through letā€™s say - very theoretical and unlikely - modified konsole settings would be a much more serious reason.

Once VM B and VM C are compromised, there is also a ton of other attack vectors to link them. One is keystroke / mice fingerprinting. Another one desktop resolution. Or any VM side channel attack. Who knows what else.

1 Like
4

After reading, the thought that comes to mind is that snapshots and Disposable VMs contribute to an air of invincibility. Users might feel free to engage in more risky behavior because they think, ā€œWho cares if I get compromised? As long as my hypervisor is safe, I can rollback or toss the VM.ā€ In reality, every compromise could fingerprint the VM so severely that linkage might be trivial in the future.

Unlike some of the settings you mentioned, uniquely configured apps tend to be similarly configured in every template and regardless of distribution - for example, a dedicated vim user will frequently have a unique configuration that will survive even a jessie ā†’ stretch upgrade. The only way to prevent such fingerprinting is not to be compromised in any VM. Using a Disposable VM isnā€™t a license to be reckless.

Will work on that.

1 Like
5

Related issues why itā€™s sometimes bad to share files in templates: