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

Mon Feb 16 03:56:50 CET 2015

On 2015-02-16 1:11 am, Hakisho Nukama wrote:
> <snip>
> 
> Optimally the underlying VM wouldn't expose hardware information at 
> all.
> Apart from a default sanitized set of 1 CPU at X Mhz and Y MB RAM,
> disk and network controller and default input and output devices,
> with guaranteed resources and restriction on maximum resource 
> utilization.
> 
> So every workload running in an anonvm under these constrains should
> behave exactly identical, whether it runs on laptop A, laptop B or 
> desktop C
> and should not be influenced by other task running on the host machine
> (and vice versa, running task on this appvm shouldn't influence host 
> machine).
> 
> VirtualBox used with Whonix does hide the processor model and 
> capabilities,
> but not frequency.
> Is there a way in cloaking all these information with modifications to
> a hypervisor?
> Or is there a reliable way to mask these information with a customized 
> kernel?
> 
> This could evaporate the need of an anonymously obtained extra piece of
> hardware for low risk situations.
> 
> <snip>

Very important!!

I was going to post on this CPU/hardware fingerprinting issue soon.

Currently, Qubes/Xen exposes the underlying host CPU information.

Just try running this in any ordinary VM...

cat /proc/cpuinfo

And so *ANYTHING* that has access or gets access to your VMs will know 
your unique machine's CPU info.

Qubes is based on the concept that the bloated monolithic OSes (Linux, 
Windows, etc) that the individual VMs run on are relatively easy to 
exploit and penetrate into. So, for security, Qubes implements very 
strong isolation between VMs to counter this threat.

However, when applied to the goal of privacy/anonymity, Qubes isolation 
breaks down when such underlying host information is freely given and 
exposed to VMs. And so even AnonVMs can be easily fingerprinted as very 
likely belonging to the same human person (e.g. exact same CPU info 
recorded between multiple compromised AnonVMs).

I'd be very interested in answers or solutions to Hakisho's question 
of...

"Is there a way in cloaking all these information with modifications to 
a hypervisor?"

Can Qubes sanitize the CPU -- and other unique hardware -- information 
passed down from the Xen hypervisor to VMs?

This would be very important for any platform supporting 
privacy/anonymity, as even VirtualBox seems to go further with.

Fixed dedicated resource utilization in VMs would be the ultimate as 
Hakisho suggests, but at least simply sanitizing unique hardware info 
would be a basic first step.

I also wonder if anybody here knows of other unique host information or 
hardware (beyond the CPU or internal VM IP) that gets exposed to 
ordinary VMs, or documented methods for testing such things?

I'm going to be exploring this issue in greater depth this year for 
Qubes + Whonix and am hungry for all the good info I can get.

But, the big blatant AnonVM fingerprinting issue I noticed so far, for 
Qubes, was the leak of unique host CPU info to all ordinary VMs.

CC'd to whonix-devel