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

Mon Feb 16 10:38:49 CET 2015

On 02/16/15 03:56, WhonixQubes wrote:
> 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
> 
> 
> 

Xen has support for emulating CPUID for HVM guests -- take a look at the
config examples in:

xen-4.1.6.1/tools/examples/xmexample.hvm-stubdom

I haven't played with it, but see no reasons it should not work. I can
imagine we introduce a prefs for VMs (say "generic_cpuid" settable via
qvm-prefs) that would be resulting in additional config for cpuid
emulation inserted in the config file for such VMs. We would need to
agree on good-enough-for-everybody CPUID config and stick to it then.
Again, this would be use-able for anon VMs mostly.

However, this will not work for PV VMs, because the CPUID instruction is
not a privileged instruction, so malware in a PV VM can always execute
this instruction (even if we hooked Xen interface for CPUID-like info to
the guest) without trapping into XEN in PV operation.

AFAIU, there are not personal identifying info returned by CPUID, but I
can see how this could be used as an additional fingerprinting vector.
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.

Let me also point out the already discussed-multiple-times topic of
potential covert channels between cooperative VMs, which might also be
potentially exploited in some scenarios to fingerprint user environment.
That is more difficult to address on PC architecture though, but some
work on Xen-level is nevertheless very welcome (see #817).

Thanks,
joanna.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://www.whonix.org/pipermail/whonix-devel/attachments/20150216/7fe09517/attachment.sig>