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

Thu Feb 19 00:46:58 CET 2015

On Wed, Feb 18, 2015 at 8:54 PM, WhonixQubes <whonixqubes at riseup.net> wrote:
> 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.

Not at all. I was talking about local deanonymization.

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

Yes. There is nothing you can do about it.

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

Uh, you can be deanonymized just by tracking the usage patterns.
However, a disposable/read-only VM would provide some measure of
protection against exploit persistence.
>From what I know, Tor/Anon VMs are not disposable (yet). This should
be the first goal.

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

No. CPUID provides only a few more bits of entropy for deanonymization.

As opposed to, say, free memory and CPU use, which is a direct
indication of usage.

-- 
Radosław Szkodziński