Revealing Qubes VM internal IP addresses with javascript

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Noticed this exchange on Twitter:[1]

Nicholas Weaver ‏@ncweaver:
>
> Grabbing global IP from javascript: yeah, whatever. Grabbing LOCAL
> IP? Trez cool: https://diafygi.github.io/webrtc-ips/

Paul Harvey ‏@csirac2:
>
> @ncweaver @thegrugq Fun. Reveals IP of Qubes AppVM. Given
> idiosyncratic IP numbering of these VMs, it's a signal the subject
> is using Qubes

Correct internal (Qubes VM) IP address is indeed shown when visiting
the demo page[2] with regular Firefox in a standard Qubes
AppVM/DispVM. (Note that it's blank when using Tor Browser in an
AnonVM, even when javascript is enabled, maybe because the STUN
request doesn't go through.) Does this have any security implications
for Qubes?


[1]https://twitter.com/csirac2/status/561338325387055105
[2]https://diafygi.github.io/webrtc-ips/
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU31SEAAoJEJh4Btx1RPV88q8QAKCWpiv7ZbYzYp0swd++Xthy
B9bEbia/YUClHepTGCega7aESUg64FM5MNM1AHr0xlcae/mvIio6c+MzQS+6IX9w
g1Su17w+8phH43kn4YuwI4M2QZcXHrtslydiGEHRzv0eO7Kc1B9P568y6oqA2E4i
S7urFHIlYHRczkv+6XeVgV7SnuEbYtL0jjR6Y4uEtu8takep9G0isa1q8sfALyx2
n0IIGBGcR5zyE7CAzpI5oqNI2+kkF9m2oje/V3s11dnyGiURY4KPBmvFFlAqNDsX
fyWEUR40HF7zY/uvpBxjm2lTmjgmSozRrJ0sqA2qR5pcwJm2BvkdVlZFAOEXbAYo
PqcdWhEPonBERARpg+CKfiw8WNRZEM5KDBdCGqwYs2epWj0b7zKuZeFNFBVWKe49
efATzKKWDRJf4ZpIeL9ZT4gVevRU8uc25oHvIYSKpwyZD+N6QoMMbHZRfDf9VqyO
qpR0M7DRLn8WENoeztma1G1i+8A2y2w4GDeZpf7BKkKq5MvRG6zEOxOCAy23lLIv
iDqfP4PHwHR73gEkJKyHTOA/3QtPmkCp/e0d+BEeuEOsA+urvQJYXH2xtgR8R9p5
9QsAyp9EqwKnbRj7BQePEIBq6XztotiJsM4qS/0lGL8ntMAl/ZHSbk4YGxMI2WWF
V9SEe1VFhck3BC92KdzY
=gjWH
-----END PGP SIGNATURE-----

[ad...@privacy.cat]

Are you sure about that?  I'm running an Firefox on an unmodified DispVM, and that page does not display my local IP address.

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ad...@privacy.cat wrote:
> On Saturday, February 14, 2015 at 11:58:40 PM UTC+10, Axon wrote:
>>
> Noticed this exchange on Twitter:[1]
>
> Nicholas Weaver ‏@ncweaver:
>>>>
>>>> Grabbing global IP from javascript: yeah, whatever. Grabbing
>>>> LOCAL IP? Trez cool: https://diafygi.github.io/webrtc-ips/
>
> Paul Harvey ‏@csirac2:
>>>>
>>>> @ncweaver @thegrugq Fun. Reveals IP of Qubes AppVM. Given
>>>> idiosyncratic IP numbering of these VMs, it's a signal the
>>>> subject is using Qubes
>
> Correct internal (Qubes VM) IP address is indeed shown when
> visiting the demo page[2] with regular Firefox in a standard Qubes
> AppVM/DispVM. (Note that it's blank when using Tor Browser in an
> AnonVM, even when javascript is enabled, maybe because the STUN
> request doesn't go through.) Does this have any security
> implications for Qubes?
>
>
> [1]https://twitter.com/csirac2/status/561338325387055105
> [2]https://diafygi.github.io/webrtc-ips/
>>
>

> Are you sure about that? I'm running an Firefox on an unmodified
> DispVM, and that page does not display my local IP address.
>

Indeed, it did display mine. I'm not sure why it didn't display yours.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU356+AAoJEJh4Btx1RPV8YbUQAO4ETre6Z5i3cJeOfVxPGi0+
1N831J7SID0cIkShqw9HX4pVjszvjT5sryw5Vz52fiOCcHaWO0240bLCtyYtvbRs
L5wnTkheEAWx1wLGH6/eNf6fCdA48b87ZVMuQpnzJQ7lZID/MIaTIuyplDYsPfcS
VDU+IA/+axS/whxN94ySOHANmsMtz3X35OnmY0+MIj24rdWWVyt8erYW0aNjEZR4
nzp7kDABXSt05tpLx4nM3hLajDlwsVRKN+cImhCjBDxlHWLB/6I+6YubeLPDFTBM
LaehgKvxLRn1JtFs4JaJTWBXOlz4KbU9QxTKcq/FbX4wTKW40pNMYQMCG+lHymdz
kP3OA3HREbpaZMzh7ey4ACpcUCTWbRFOo/tW8PxVqEsJ4ZB1rX3UnJzMDGf5xZ37
1z94fu6O80s5mWeTgqIQbNlMTeaQfQ5RNzNV/M7n/8qKuHA+tFsLJybK5d188vwY
OLgJr57ep+AevUHbV+VTvuwPYM/NIguZS1EL5wTTUeomvscJHcOaabNftNQWJPAF
EYWGJOcv5rssDHRVIVp47FLWvhUS9PcX3eCGgews0V1K48pc6f0EhNN9IhDdM+uw
aN1zaP4J4plLfeaAcZHOu3xa7dXvhwtFh8TOtlEBMnOlnCcLYY2C4xE81S8by7oc
WSGwerGhH1ROl7qTmyO1
=eJ6f
-----END PGP SIGNATURE-----

[7v5w7go9ub0o]

On 02/14/15 14:15, Axon wrote:

> ad...@privacy.cat wrote:
>>
>> Are you sure about that? I'm running an Firefox on an unmodified
>> DispVM, and that page does not display my local IP address.
>>

> Indeed, it did display mine. I'm not sure why it didn't display yours.

Displayed on mine (dispvm) as well.

Needed to go to <https://twitter.com/csirac2/status/561338325387055105>
first; link to reference; activate JS.

[cprise]

Consider that any successful attack on a connected vm would also yield a LAN IP address... So its probably not a core security concern, although the fingerprinting it allows may be worrisome.

First question is whether we want products like Firefox casually facilitating the discovery of a non-exploited system's address. (Admittedly, NAT traversal is an important feature for some apps, though its not clear to me it should happen in a web browser or without asking the users' permission.)

Second question is whether Firefox already has a setting that can be changed to prevent the address reveal. (The answer to this appears to be 'No', and addons seemingly can't help either.)

Third question is whether Qubes can help, either by changing its internal network to a range that blends in more, or perhaps firewall rules that block STUN (though I think the latter is unlikely).

[Hakisho Nukama]

Google Chrome is also showing LOCAL_IP.

I currently see the most critical part in deanonymising persons using
(persistent) VMs connected to a proxyvm.

Currently the address space is assigned dependent on order of creation of
netvm, proxyvm and their dependent {disp,app}vms [0].

A random IP at every VM start could be assigned out of a pool of addresses
defined for anonymous/pseudonymous use cases [1]
(enabling use of more than one anonvm concurrently,
otherwise one LOCAL_ANON_IP could be specified).
Maybe even create a RFC@IETF for a pool of anonymous use and
get other projects aboard? ;)
172.16.1.100-150 [2]
10.152.152.? [3]

Optimally the underlying VM wouldn't expose hardware information at all.
Apart from a default sanitized set of 1 CPU@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.

And practice your OPSEC and don't let untrusted code run on your system
- disable JavaScript, Flash, Java, ...
- use deterministic builds out of trusted sources and signed by your
web-of-trust
- configure your system according to a trusted configuration approved by you
(Configuration Management) which was signed by your web-of-trust

Then you've to keep in mind, that other attacks are still possible to
get your head cut-off. :(

Best Regards,
Hakisho Nukama

[0] https://groups.google.com/d/msg/qubes-devel/Dd0MVbIam5I/U3C_7wCFQ7sJ
[1] https://groups.google.com/d/msg/qubes-devel/C1D5_tbl4jM/he3cra8oKk8J
[2] https://github.com/grugq/portal
[3] https://www.whonix.org/

[WhonixQubes]

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

[Zrubi]

On 02/16/15 03:56, WhonixQubes wrote:

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

I just wonder what part is unique in the output of cpuinfo? :O


And the ones who want to hide this:
CPU is NOT virtualized in any hypervisor. So at least your kernel have
to se it as is.


* not sure about Xen but VMware ESXi can mask several CPU features - but
this is not a security feature instead they made it for better cluster
node compatibility.


--
Zrubi

[Zrubi]

On 02/14/15 14:58, Axon wrote:

>> @ncweaver @thegrugq Fun. Reveals IP of Qubes AppVM. Given
>> idiosyncratic IP numbering of these VMs, it's a signal the subject
>> is using Qubes
>
> Correct internal (Qubes VM) IP address is indeed shown when visiting
> the demo page[2] with regular Firefox in a standard Qubes
> AppVM/DispVM. (Note that it's blank when using Tor Browser in an
> AnonVM, even when javascript is enabled, maybe because the STUN
> request doesn't go through.) Does this have any security implications
> for Qubes?

I don't think that this is related to STUN.

javascript (and flash, and silverlight, etc) are running on your local
browser. What they can see from your OS and filesystem is depends on the
used browser - but that means EVERITHING in general.



--
Zrubi

[WhonixQubes]

On 2015-02-16 8:03 am, Zrubi wrote:
> On 02/16/15 03:56, WhonixQubes wrote:
>
>> And so *ANYTHING* that has access or gets access to your VMs will know
>> your unique machine's CPU info.
>
> I just wonder what part is unique in the output of cpuinfo? :O

Just about everything from "/proc/cpuinfo" is unique to the user's host
machine, which could easily narrow down personal identities to very
small amounts, if not the individual level.

Example from: cat /proc/cpuinfo

processor :
vendor_id :
cpu family :
model :
model name :
stepping :
microcode :
cpu MHz :
cache size :
physical id :
siblings :
core id :
cpu cores :
apicid :
initial apicid :
fpu :
fpu_exception :
cpuid level :
wp :
flags :
bogomips :
clflush size :
cache_alignment :
address sizes :
power management:

On 2015-02-16 8:03 am, Zrubi wrote:
> And the ones who want to hide this:
> CPU is NOT virtualized in any hypervisor. So at least your kernel have
> to se it as is.

Would it really take full CPU virtualization to mask the unique CPU
hardware info to the VM kernels?

Also, in the Qubes Manager, under Settings --> Advanced for a VM, one
has the option of "VCPUs no.". Where, seemingly, this option selects the
number of virtual CPUs available to the VM?

[Joanna Rutkowska]

On 02/16/15 03:56, WhonixQubes wrote:

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.

[cprise]

Getting back to parent thread's topic: The discovery of LAN IP address does not even require any intrusion/exploit into the system... it's really just a feature.

But being on a '10.137' net is probably more identifying than having, say, an i5-3320M stepping 7 processor.

So perhaps Qubes should have a configurable LAN address (like a regular router does) so that concerned users/admins can change it to something that is common but also works within their LAN environments.

[Joanna Rutkowska]

Patches welcome :)

[7v5w7go9ub0o]

Yikes! to all of this!

1. A grsecurity patched kernel can use RBAC (its variety of MAC, or
mandatory access control, to block user (and root) access to just about
anything desired. It utilizes its own user-defined RBAC password. This
solution would be for "hard-core" users. (there is also a SeLinux
equivalent - used to be harder to implement)

<https://wiki.archlinux.org/index.php/grsecurity#RBAC>

2. There may be something here; but IIUC would require a root password
to be effective:
<http://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/>

[WhonixQubes]

Hi Joanna,

On 2015-02-16 9:38 am, Joanna Rutkowska wrote:
>
> 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 looked through the CPUID feature in this example file:

-
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=tools/examples/xmexample.hvm-stubdom;hb=stable-4.1

More general info on CPUID for others:
- https://en.wikipedia.org/wiki/CPUID

Some of the very low-level x86 implementation details of it are beyond
me currently, but, from what I can glean it looks like it is generally
the right type of thing, since it seems to be baked into the Xen Dom0
layer beyond the reach of the HVM's OS.

Would be looking for AnonVMs to simply not be able to know what CPU the
host machine is running on, by any means (barring covert channels or Xen
breakouts), but even including privilege-escalated malware in the VM.

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

Sounds good.

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

Yes. Sounds like a plan.

I'm guessing that this would *not* limit the speed of the CPU(s) that
the HVM is exposed to? Just changes the info/attributes of the AnonVM
domain's CPU (including reported MHz?)?

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

That's too bad for excluding paravirtualized VMs.

However, if there is no way to achieve a masked CPU with PVMs, then so
be it.

Given the general statistical environment of AnonVM users, I think
unique CPU info is too important of a de-anonymization vector to hold
onto PVMs for.

> AFAIU, there are not personal identifying info returned by CPUID, but I
> can see how this could be used as an additional fingerprinting vector.

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
- # of Qubes + Tor AnonVM Users
- # of Qubes + Whonix AnonVM Users
- # of CPU Model Info
- # of CPU Microcode Version

...should be pretty easy to reveal individual people through their usage
of Qubes privacy/anonymity this way.

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.

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

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

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

Yes. I have read through some of your stuff on covert channels in the
past, including in the original Qubes architecture spec doc.

Just read through the thread linked in Qubes ticket #817 from 2014. Good
stuff.



WhonixQubes

[Joanna Rutkowska]

On 02/17/15 11:55, WhonixQubes wrote:
> Hi Joanna,
>
>
> On 2015-02-16 9:38 am, Joanna Rutkowska wrote:
>>
>> 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 looked through the CPUID feature in this example file:
>
> -
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=tools/examples/xmexample.hvm-stubdom;hb=stable-4.1
>
>
> More general info on CPUID for others:
> - https://en.wikipedia.org/wiki/CPUID
>
> Some of the very low-level x86 implementation details of it are beyond
> me currently, but, from what I can glean it looks like it is generally
> the right type of thing, since it seems to be baked into the Xen Dom0
> layer beyond the reach of the HVM's OS.
>

The CPUID interception is implemented in the hypervisor via VT-x. Dom0
has nothing to do with that...

> Would be looking for AnonVMs to simply not be able to know what CPU the
> host machine is running on, by any means (barring covert channels or Xen
> breakouts), but even including privilege-escalated malware in the VM.
>
>
>
>> 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.
>
>
> Sounds good.
>
>
>
>> 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.
>
>
> Yes. Sounds like a plan.
>
> I'm guessing that this would *not* limit the speed of the CPU(s) that
> the HVM is exposed to? Just changes the info/attributes of the AnonVM
> domain's CPU (including reported MHz?)?
>
>

No.

>
>> 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.
>
>
> That's too bad for excluding paravirtualized VMs.
>

BTW, it should be obvious, but let me point out that any
compartmentalizing technology for x86 that is *not* based on VT-x/AMD-v
would be prone to this problem. This is b/c CPUID is an *instruction*
and its execution cannot otherwise be controlled by the OS, other than
via VT-x intercept.

> However, if there is no way to achieve a masked CPU with PVMs, then so
> be it.
>
> Given the general statistical environment of AnonVM users, I think
> unique CPU info is too important of a de-anonymization vector to hold
> onto PVMs for.
>
>
>
>> AFAIU, there are not personal identifying info returned by CPUID, but I
>> can see how this could be used as an additional fingerprinting vector.
>
>
> 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
> - # of Qubes + Tor AnonVM Users
> - # of Qubes + Whonix AnonVM Users
> - # of CPU Model Info
> - # of CPU Microcode Version
>

FWIW, CPU ucode, AFAIK, is not CPU-persistence -- it is applied on each
boot.

> ...should be pretty easy to reveal individual people through their usage
> of Qubes privacy/anonymity this way.
>
> 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.
>
>

Other platforms simply do not offer any meaningful separation between
the apps that primary targeted apps (e.g. a Web browser used for anon
browsing) and the hw specific personal identifying info (NIC MACs, IP,
avilable WiFi networks in the neighborhood, etc). In these case if the
attacker (e.g. NSA) exploits your anon Web browser they already get you.
In case of Qubes they can start gather info such as CPUID output and
mining through a database of Qubes users. Quite a different level of
threat IMHO.

>
>> 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.
>
> Another anonymity upshot of HVMs is their, by default, non-seamless
> fixed single windowing.

You can have seamless GUI for HVM VMs.

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

Don't quite get it? Like 1600x900 instead of 1920x1080 you mean?

> Not as bad of an attribute as the host's
> unique CPU info, 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.
>

>
>
>> 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).
>
>
> Yes. I have read through some of your stuff on covert channels in the
> past, including in the original Qubes architecture spec doc.
>
> Just read through the thread linked in Qubes ticket #817 from 2014. Good
> stuff.
>
>
>
> WhonixQubes
>
>

joanna.

[WhonixQubes]

On 2015-02-17 11:28 am, Joanna Rutkowska wrote:
> On 02/17/15 11:55, WhonixQubes wrote:
>> Hi Joanna,
>>
>>
>> On 2015-02-16 9:38 am, Joanna Rutkowska wrote:
>>>
>>> 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 looked through the CPUID feature in this example file:
>>
>> -
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=tools/examples/xmexample.hvm-stubdom;hb=stable-4.1
>>
>>
>> More general info on CPUID for others:
>> - https://en.wikipedia.org/wiki/CPUID
>>
>> Some of the very low-level x86 implementation details of it are beyond
>> me currently, but, from what I can glean it looks like it is generally
>> the right type of thing, since it seems to be baked into the Xen Dom0
>> layer beyond the reach of the HVM's OS.
>>
>
> The CPUID interception is implemented in the hypervisor via VT-x. Dom0
> has nothing to do with that...
>

Err, oops, duh, I know better. I often conflate the terminology of Xen
Hypervisor and Xen Dom0. Yes, rather, I meant Xen Hypervisor. :)

>> Would be looking for AnonVMs to simply not be able to know what CPU
>> the
>> host machine is running on, by any means (barring covert channels or
>> Xen
>> breakouts), but even including privilege-escalated malware in the VM.
>>
>>
>>
>>> 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.
>>
>>
>> Sounds good.
>>
>>
>>
>>> 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.
>>
>>
>> Yes. Sounds like a plan.
>>
>> I'm guessing that this would *not* limit the speed of the CPU(s) that
>> the HVM is exposed to? Just changes the info/attributes of the AnonVM
>> domain's CPU (including reported MHz?)?
>>
>>
>
> No.
>

Ok, so, *No*, it will not limit actual CPU operating speed.

But, would it also mask/fake the *reported* CPU speed info to being
something universal/generic?

The former is a huge reason why I use Whonix in VMs, because of this
fundamental architectural problem with systems like Tails, etc, which
have access to bare metal and don't isolate the Tor proxy from apps.

With the latter scenario in Qubes, it does take an added step of linking
2 data points together, in order to identify multiple AnonVMs as being
owned by the same pseudonymous or real world user.

A big part of the problem here is that so few people are using Qubes +
Whonix, that if 2 AnonVMs got trivially popped (via Firefox,
Thunderbird, PDF, IMG, etc) and had the same CPU specs, it would no
doubt predictably be the same user/person out in the world using that
instance of Qubes + Whonix, since there are probably many more CPU
models than such users at this point.

And if there is any personally identifying info/documents/etc inside one
of the VMs, then it's a true identity game over for all known AnonVM
activity simply tied back to a CPU model.

With GOV netflow and other vast personal activity history, such as
technology purchases, software statistics/debug uploads, Qubes HCL
report contributions, etc, it only gets easier to filter out key
information and potentially infer identity based on 1 single AnonVM
compromise.

By making the AnonVM OS technical environment entirely
universal/generic, people could have multiple pseudonymous and/or
personally identifiable info inside AnonVMs, and still have some
meaningful confidence that they couldn't be linked by 1 or 2 intrusions
of some simple malware.

I personally wouldn't be one bit surprised if such a de-anonymization
has already happened for a Qubes AnonVM user based on these
same-or-similar technical fingerprinting methods.

>>
>>> 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.
>>
>> Another anonymity upshot of HVMs is their, by default, non-seamless
>> fixed single windowing.
>
> You can have seamless GUI for HVM VMs.
>
>> 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?).
>
> Don't quite get it? Like 1600x900 instead of 1920x1080 you mean?
>

Yes. Host machine screen pixel size and bit/color depth values.

In a Qubes VM/AnonVM one can run:


printenv


and get H=height, W=width, D=depth as the host machine's actual hardware
display.

or install something like "hardinfo" package to view in GUI

It's yet another hardware fingerprint value that is semi-unique to the
user's configuration.

VirtualBox + Whonix, for example, on purpose for a privacy/anonymity
optimized environment, has a default universal/generic screen size
setting of 1024x768.

And same 1024x768 universal/generic screen size exists with the original
Qubes + Whonix HVM port.

>> Not as bad of an attribute as the host's
>> unique CPU info, 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.
>>
>
>>
>>
>>> 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).
>>
>>
>> Yes. I have read through some of your stuff on covert channels in the
>> past, including in the original Qubes architecture spec doc.
>>
>> Just read through the thread linked in Qubes ticket #817 from 2014.
>> Good
>> stuff.
>>
>>
>>
>> WhonixQubes
>>
>>
>
> joanna.

WhonixQubes

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

WhonixQubes wrote:
> On 2015-02-17 11:28 am, Joanna Rutkowska wrote:
>> Other platforms simply do not offer any meaningful separation
>> between the apps that primary targeted apps (e.g. a Web browser
>> used for anon browsing) and the hw specific personal identifying
>> info (NIC MACs, IP, avilable WiFi networks in the neighborhood,
>> etc). In these case if the attacker (e.g. NSA) exploits your
>> anon Web browser they already get you. In case of Qubes they can
>> start gather info such as CPUID output and mining through a
>> database of Qubes users. Quite a different level of threat IMHO.
>
> The former is a huge reason why I use Whonix in VMs, because of
> this fundamental architectural problem with systems like Tails,
> etc, which have access to bare metal and don't isolate the Tor
> proxy from apps.

Speaking of this, the Tor Porject has had a ticket open for over 2 years
now about wanting to "Wrap Tails inside a VM, where the out VM runs
Tor and handles the network."[1]

Interestingly, the latest post from Erinn Clark (7 months ago) was:

"What should we do with this ticket? Leave it here? Assign to Tor VM
(what is that?)?"

But I'm pretty sure she's not referring to Qubes TorVM. (Apparently
there's something else associated with the Tor Project called "Tor VM.")

It would be cool if Qubes ended up being the solution for this.


[1]https://trac.torproject.org/projects/tor/ticket/7681
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU42d+AAoJEJh4Btx1RPV8Nh8P/1tfkHPRNF8vLZvvfkw4g1KU
/RljHONhdcOqVjf+JJLz8jDvSDAOXXNU/XoVDF5q09cDzJjjVbK0ZQup451ZcGD+
DPsbXBZIpP9upQStgFKazzz3gh0z2aLoB/3wztuvgm+fZ3ab4xidhROgguiwSv1Z
BvrjjRpe+UUYS3ycV1rSZXyz80gVnRAiWDH/l0CjzbRxHpaxPsRFEY43++pVfWq1
FSXRaeGQGQOU6kiWaxcc5YpCfJ/zFFQsxEpEasIyNpuGY0bvNMtJmlRS38v9xjxc
ccouq4jKyqhHgWrK+qN9RTcoiY1qyWADDRkmycc4yMNWWpJ4hBcDfjWs92Z7uLiP
AUNvIk1Fa7NPlLppwDIlKQ+9NS3csMcjKUNn5Yn2X8TbWOqFSEh1l9KPxTunz3Z0
EZB+/aLM453EIr6yRVPm1kXOnY4QZdghxBzYL9ueiBgwc9EqUgnCWmahVwa2aQYq
C9SEj+o7bwjjZyXEmXJ5m/Zcdr5DSs7iDJRi8AdwX/8I7EZTZDMhOps+unPWOEo8
+ZxpjheisyY7aM+QvLeedzN5fChKpTq5GYNMZ4SXmvzg61BhLx6TqBo+xkZ+8o30
Pu0o16Yq/QF+6QKU56sg8RGvEYpZvDQo5OqBi2Eha/ausG252jQiEq1CQVVDcKTA
yLQZQnluNjqhc46f+YTc
=AR2c
-----END PGP SIGNATURE-----

[WhonixQubes]

Yeah, I saw this issue back when I was considering what would be best to
develop for a great Qubes + Tor platform.

Also see this page for more info:

https://tails.boum.org/blueprint/Two-layered_virtualized_system

Tails isolation seems like a dead effort for some time now.

WhonixQubes

[Radoslaw Szkodzinski]

On Tue, Feb 17, 2015 at 11:55 AM, WhonixQubes <whoni...@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.

--
Radosław Szkodziński

[WhonixQubes]

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

[Radoslaw Szkodzinski]

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

[Unman]

On Thu, Feb 19, 2015 at 12:46:58AM +0100, Radoslaw Szkodzinski wrote:
<snip>

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

Am I missing something? It's trivial to make the dispvm an 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.
>
> 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.

Yes, this is right. It's just not true that CPU info is a unique
identifier although it's been repeatedly claimed in this thread.

look at the browser fingerprint of the TBB - sometimes I think you would
be better off running IE on XP with a cheap mass market pc. :-)

And is this local IP exposure disclosure anything new? I've seen
javascript leveraging java calls before to get local IP adresses.

[WhonixQubes]

On 2015-02-18 11:46 pm, Radoslaw Szkodzinski wrote:
> On Wed, Feb 18, 2015 at 8:54 PM, WhonixQubes <whoni...@riseup.net>
> wrote:
>> 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.
>

Ok, great, my mistake.

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

Don't you believe the AnonVM OS environment can be given a generic
fingerprint? If not, then why?

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

What kind of usage patterns are you thinking of that couldn't be
mitigated by proper AnonVM isolation?

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

Yes. Amnesic usage of AnonVMs is important.

One can do it now with AnonVMs, either with manual destruction
(inconvenient) or scripting it (better convenience), by leveraging the
TemplateVM.

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

I see how CPU work speeds could identify a unique underlying machine.

AFAIK, all AppVMs/AnonVMs by default are given a generic dynamic range
of 400MB to 4000MB of RAM.

How would free memory in AnonVMs be able to identify a unique underlying
machine?

[WhonixQubes]

Hi Unman,

On 2015-02-19 1:10 am, Unman wrote:
> On Thu, Feb 19, 2015 at 12:46:58AM +0100, Radoslaw Szkodzinski wrote:
> <snip>
>> >
>> > 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.
>
> Am I missing something? It's trivial to make the dispvm an anonvm...
>

I thought there was a killer issue with this, although, unfortunately it
is escaping me at the moment.

But, yes, getting a Whonix DispVM would be good.

It is on my TODO to look into further.

>>
>> >
>> > 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.
>
> Yes, this is right. It's just not true that CPU info is a unique
> identifier although it's been repeatedly claimed in this thread.

Unfortunately, I think CPU info is a unique machine identifier at this
point. There are only a handful of people using certain kinds of AnonVMs
right now (especially thinking of the new Whonix templates).

So it is likely that your CPU model would uniquely identify your
machine, or at least provide extremely narrow targeting of a few people.

On Qubes AnonVMs, we are the needles without a haystack.

We either need a haystack of lots of AnonVM users with the same
hardware, or we need to make the unique hardware spec info appear
generic to AnonVMs.

> look at the browser fingerprint of the TBB - sometimes I think you
> would
> be better off running IE on XP with a cheap mass market pc. :-)
>

LOL. ;p

> And is this local IP exposure disclosure anything new? I've seen
> javascript leveraging java calls before to get local IP adresses.

I think if people want to better protect their personal exposure, then
they should use Tor Browser in a proper AnonVM environment.

Tor Browser did not expose the local Qubes IP for me when used the test
page with JavaScript on.

Asking generic software and browsers to protect your system's technical
fingerprint is a bit of an oxymoron I think.