[Whonix-devel] [qubes-devel] Re: Exposing AnonVM Users with Dom0 Hardware Fingerprint Leaks

Wed Feb 18 20:54:02 CET 2015

On 2015-02-18 8:40 am, Radoslaw Szkodzinski wrote:
> On Tue, Feb 17, 2015 at 11:55 AM, WhonixQubes <whonixqubes at riseup.net> 
> wrote:
>> Right.
>> 
>> For example, subdividing the cross-section of privacy/anonymity users 
>> by the
>> following attributes would no doubt be a privacy/anonymity killer for
>> individual human identities...
>> 
>> # of unique combined mixtures of the following attributes:
>> - # of Qubes Users
> 
> This is relatively easy, because all Qubes users would look similarly
> thanks to the local IP address.
> Contingent on being able to retrieve local IP or MAC address - which
> is not trivial in a privacy-minded setup.
> Other information looks like a Fedora system with hardware not
> supporting OpenGL.
> 
>> - # of Qubes + Tor AnonVM Users
> 
> This would require correlating previous step with the list of Tor exit
> nodes or using a hidden service for a callback.
> 
>> - # of Qubes + Whonix AnonVM Users
> 
> This is actually much harder, there's not enough information to
> discern between Tor AnonVM and Whonix AnonVM I think.
> 
>> - # of CPU Model Info
>> - # of CPU Microcode Version
> 
> This information is hard to get, unless you crack every one of the
> people above - and then, you have to be sure they do not use the same
> CPU model.
> To do so, you need to break Tor or, say, JavaScript implementation of
> most browsers. Then at least access /proc/cpuinfo.
> Alternatively, run a plugin which allows access to such information.
> (Java comes to mind.)
> 
> Fortunately, CPUID does not provide Processor Serial Number in any 
> recent CPU.
> 
> Microcode can be either updated when starting Xen via
> ucode=<number|scan> and the microcode image in number case or
> initramfs with early microcode in scan case.
> If Qubes updated the microcode for everyone (a generally good idea),
> that could be ignored. Xen 4.4 supports it, so it could be done for
> r3.
> I think dracut supports adding microcode to the initramfs, so would
> just have to add the parameter.
> 
>> ...should be pretty easy to reveal individual people through their 
>> usage of
>> Qubes privacy/anonymity this way.
> 
> No. Again, the hardest step is the last one - breaking out of the
> sandbox of the web browser.
> Once you have local access, there is enough ways to fingerprint
> everything imaginable that you've lost.
> 
>> Although, AFAIK, other platforms are not totally immune from this. 
>> Some just
>> have a higher # of total users out in the world, but at their 
>> technical
>> expense of lacking strong security isolation to protect the integrity 
>> of
>> their privacy/anonymity systems.
> 
> Disable JavaScript, plugins, OpenGL. (e.g. NoScript) Disable cookies.
> You are then depending on the web browser's security of this mechanism
> and should be left with a vastly smaller TCB.
> It also becomes much harder to identify you as a Qubes user as well.
> 
>>> Thus, perhaps we should consider distributing Whonix workstation
>>> template as an HVM template instead of a PVM one? Fortunately we do 
>>> have
>>> templates support for HVMs, so this should be perfectly possible.
>> 
>> 
>> 
>> Assuming there is no feasible way to accomplish this objective with 
>> PVMs,
>> then implementing the Whonix-Workstation in a HVM template with
>> "generic_cpuid" sounds like the right move.
> 
> Available free memory in the VM is a much better predictor of the user
> and usage than CPUID.
> Especially if you allow the VM to balloon (automatically resize 
> memory).
> This information is even available from JS in Chrome. (but not Firefox
> to my knowledge)
> 
>> Another anonymity upshot of HVMs is their, by default, non-seamless 
>> fixed
>> single windowing. Even though the seamless desktop mode of the new 
>> Qubes +
>> Whonix platform is sexy and smooth to use, it does expose another
>> semi-unique host machine attribute to the AnonVMs, which is the host's
>> unique display resolution size and pixel depth (maybe some other 
>> related
>> stuff too?). Not as bad of an attribute as the host's unique CPU info,
> 
> CPUID does not have unique CPU info - Processor Serial Number is not
> implemented there in modern CPUs.
> 
>> but
>> still would be best to make use of the fixed single windowing for 
>> AnonVMs so
>> this could be generic. Maybe both seamless and non-seamless windowing
>> options could be offered for Whonix-Workstation HVM template, since 
>> some
>> people hate non-seamless.
> 
> Why not just resize the browser window by means of the internal window
> manager or virtual display size?
> (But why are you allowing JS then?)
> 
> Much easier than tossing HVM at it, you need to patch exactly one line
> in the client VM.
> Of course someone might have a weird screen size... but again, this
> requires JS to be running.

Radoslaw,

Thanks for your extensive feedback! :)

However, we are talking at cross-purposes, I'm afraid.

You primarily seem to be talking about de-anonymization based on 
internet traffic data. Which is fine, but a level up from where I'm 
talking about here.

I'm talking about once an AnonVM has been compromised (not that hard in 
bloated OSes like Linux, etc), and the attacker can see most-or-all 
technical and user info contained within the AnonVM environment.

As various factors stand right now, based on 2 AnonVM compromises, or 
based on 1 AnonVM compromise correlated with other information 
databases, a person can be de-anonymized based on the CPU model info 
that Qubes/Xen is exposing to the AnonVM.

There are other characteristics of the AnonVM environment (especially 
non-hardware based) that make it uniquely fingerprintable in this way. I 
am personally working on programming a software solution to these types 
of "other" fingerprints in Qubes, this year in 2015.

But, as it stands, once compromised (with is pretty trivial to do), a 
Qubes AnonVM user could be de-anonymized in many scenarios based on 
their CPU info being exposed to the AnonVM.

It would just simply not be a problem/threat, if we just make the CPU 
look generic to the AnonVM, as some other virtualizers like VirtualBox 
go further with doing.

Sounds like the Xen HVM CPUID emulation module might be the fix for 
this.

WhonixQubes