Hi entr0py,

Thanks for your detailed and thorough answer.

1. Dec 2016 20:03 by 3n7r0...@gmail.com:

> hopefulf...@tuta.io> :
>> 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.

Looks like this is what I sought for. Couldn't find the ticket either - 
probably it isn't in any near scope, unfortunately.


> 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).

I'm aware of this global adversary problem. We can imagine an adversary that is 
partially powerful - like a secret service of some state - which power is 
limited to a set of ISPs within the state. The service may want to know who are 
the foreigners accessing some web resource. It cannot launch a passive attack 
as the connections enter Tor from ISPs that are not under their control (this 
also includes VPN out of the state into Tor, not so rare use case actually). In 
this case, taking control of the sys-net of a suspect gives the opportunity for 
this passive attack on Tor connection of that particular user. And it isn't 
obvious that getting access to foreign ISPs is cheaper. We can imagine quite a 
lot of possible attack vectors at sys-net too - from local (e.g. during 
compromised or public hactivist meeting) to remote (like packet in packet 
attack, [7*]). 


> 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]. 

Great! This feature is much anticipated.


> 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.

Yes, that is a well-known issue with entry guards. IMHO, a config option of 
some sort could help here - at least for those computers which are home-only or 
mobile only.


> 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.

Personally I don't think that Whonix-Gateway can be considered as trusted. It 
connects to a large set of entry guards / bridges and many of them can be 
malicious. Connections are done using C-written component - i.e. exposed to 
memory corruption issues which may lead to code execution. And even worse, its 
template is exposed to the same risky conditions. I.e. its activity is always 
under this constant risk that cannot be lowered, unlike other cases when we can 
estimate the risks and say whether we're in a low or high-risk condition.

And, just to be clear, compromise of the tor process is the instant "Game Over" 
for the anonymity (if user is relying solely on Tor). Someone may be lured into 
thinking that it is hard for an adversary to identify its targets at tor level 
and arbitrary exploitation of a 0-day in tor will be noticed quite fast, so it 
is safe overall. But ISP-level adversary can actually target any prominent 
person (like most of us - who are doing much of the stuff publicly - that is 
inevitable) - in case it gets connected to a compromised entry guard.


> 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. 

I was saying exactly the same. Unfortunately, no hardening measures can prevent 
this from happening - except hardening the Tor Browser process itself (and, of 
course, the system context it runs within - like ASLR, NX etc - but not things 
like AppArmor/SELinux or even kernel hardening). Because implementing this 
attack doesn't require any more privilege than the browser already has. Hope in 
future we'll have Servo (which is written in memory-safe Rust). And I'm 
dreaming about some limited browser written in Go/Rust, that has the same 
fingerprint as Tor Browser with high security level.


> 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 preferred.
> [1] > https://www.qubes-os.org/doc/bind-dirs
> [2] > https://svn.torproject.org/svn/projects/design-paper/tor-design.html>  
> #Section3.1
> [3] > 
> https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm/2461
> [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

[7*] https://www.usenix.org/legacy/event/woot11/tech/final_files/Goodspeed.pdf 

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