> 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.
> 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. 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. 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. 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 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. 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
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.