> Hello,
> Currently any AppVM has persistent storage, it is referenced by
> default at least as /home, /rw/config, /usr/local. And software is
> executed from this persistent storage from read-only system.

There may be additional persistent storage enabled as well[1].

> This allows an adversary to install persistent AppVM exploit e.g. via
> ~/.bashrc or /rw/config/rc.local. Advanced exploit can then hide its
> own invocation script, so it won't be possible to detect it from
> running VM itself (at least aafter /rw/config/rc.local is executed;
> so better check when VM is turned off).

Hence, all untrusted activity should be performed in a disposableVM or 
untrustedVMs with nothing of value.

> I suppose that it is by design and that won't harm other, trusted VMs
> (with an exception of unclear consequences of mounting this rw
> partition in another dom). But there is a threat model when
> persistent exploit of untrusted vm matters - the one when user wants
> to maintain anonymity.
> For example, a persistent exploit in network vm can be used to defeat
> MAC randomization and track user location; it can even help mount
> attack against Tor for an adversary that isn't user's ISP - exploit
> can monitor outgoing Tor traffic and check correlations with incoming
> traffic of investigated sites (that are within adversary's ISP).

I believe there is a ticket for disposable serviceVM (sys-net, sys-usb) 
functionality. Can't find at the moment.

Unfortunately, there are some scenarios that Tor was never designed to defend 
against. A global passive adversary that can listen on both endpoints presents 
a vulnerability for any low-latency anonymity system[2]. Also, being a specific 
target opens up many additional non-technical avenues for deanonymization that 
may be trivially simpler than attacking Tor. In your example, it's not obvious 
that an adversary who can compromise and monitor your sys-net as well as the 
connections of all of the other compromised network connections can't simply 
compromise / coerce / subpoena ISPs to perform the same function at lower cost 
(legal / reputational / computational).

> If the same is applicable to Whonix VMs, then it is even worse to
> anonymity: persistent exploit in Gateway completely defeats Tor while
> persistent exploit in Workstation can be used to deanonymise user via
> correlation analysis if attacker is controlling user's ISP (in this
> case attacker can send a controlled data stream to its own server
> over Tor and monitor incoming Tor traffic at ISP level).
> Basically, as a user with threat model that involves maintaining
> anonymity, I cannot rely on stock Qubes now - at least untrusted VMs
> should be created from templates each time I need them - and that is
> inconvenient and may have other consequences.
> I haven't found any public discussion of this persistent storage
> exploits - could you please point me to it if it is already covered?
> Any ideas how to address this issue properly?
> Thanks, Hopeful Fork

Your best bet to defend against persistent malware is to use Whonix-Workstation 
as your disposableVM template as previously suggested. Documentation is 
in-progress[3]. There is no additional threat to anonymity by using Tor all the 
time. Although stream isolation can effectively isolate your traffic across 
multiple Tor circuits, it is still advisable to use multiple VMs to separate 
your identities and never to use clearnet and Tor in the same VM[4]. You may 
find in certain cases, such as accessing your bank online, that you prefer to 
use a trusted banking VM connected directly to sys-net.

Persistent storage in Whonix-Gateway is not only a matter of convenience - for 
storing files/settings - but can also be considered a security feature. Tor 
implemented persistent entry guards to reduce the likelihood of user traffic 
being intercepted by malicious entry guards[5] and this requires persistent 
storage. On the other hand, if you are a mobile user, you may worry about your 
entry guard footprint being used to track you[6]. In that case, you may prefer 
to follow the Tails model, recreate your Whonix-Gateway VM on a more frequent 
schedule, or use multiple Whonix-Gateways.

The reason for isolating the Tor gateway from the user workstation in the first 
place is to be able to designate Whonix-Gateway as a trusted VM. Qubes VM 
isolation is relied on to maintain the integrity of Whonix-Gateway despite its 
connections to untrusted VMs. Whonix attempts to limit Gateway-Workstation 
interaction as much as possible to minimize attack surface - for example, via 
control port filters.

Workstation compromise, persistent or not, is certainly a concern that is 
hopefully mitigated by layered hardening measures, such as Tor Browser and 
Apparmor. Again, in your example, you seem to assume the adversary is a global 
passive attacker with resources significant enough to monitor all the ISPs in a 
region / countr(ies). In such a situation, the attacker doesn't necessarily 
need persistent compromise to de-anonymize the user. Once they locate and 
compromise a Workstation of interest, they can simply send out signals in a 
pattern while monitoring the ISPs. You can mitigate this situation by using 
dispVMs, which contain no identifying information (documents, logins) and being 
judicious with the amount of browsing done per VM. Simply deanonymizing random 
Tor circuits to their server only reveals that the target is a Tor user. 
Ultimately, low-latency networks are not safe against this type of adversary 
regardless of countermeasures. Something like a high-latency mailer would be 

[1] https://www.qubes-os.org/doc/bind-dirs
[2] https://svn.torproject.org/svn/projects/design-paper/tor-design.html 
[4] https://www.whonix.org/wiki/DoNot
[5] https://blog.torproject.org/category/tags/entry-guards
[6] https://www.whonix.org/blog/persistent-tor-entry-guards

You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to