[tor-talk] Practical deanonymization using CPU load covert channels

[Ethan White]

A recap (since this thread is about 2 weeks old): Ping latency decreases 
when CPU usage is high. If an adversary can influence CPU usage (i.e. 
JavaScript, GZIP decompression, expensive public-key crypto), then they 
can use this as a covert channel to transmit data. (Imagine: someone 
compromises a SecureDrop installation, and adds JavaScript, or a series 
of large, GZIP-compressed pages in iframes, to cause a distinctive CPU 
usage pattern. They then observe ping latencies of hundreds of people 
they suspect of being whistleblowers (imagine: every NSA employee). This 
should all be possible over the open Internet, but it may be necessary 
to wait for the target to use public Wi-Fi or similar to get lower 
latencies and/or not be thwarted by a NAT.)

First off, when I initially posted here, I wasn't sure why ping latency 
would decrease. some_guy123 suggested that it is CPU c-states causing 
it, and I can confirm that disabling c-states does completely prevent 
this attack. This looks promising. However, I've seen it increase idle 
wattage by up to 60%, and I've seen it increase the CPU temperature by 
up to 10 degrees Celsius, so more casual users would possibly want to 
avoid this.

 > Limiting CPU resources for Tor as opposed to the browser component is 
what counts? (both are separate in the Whonix model)

First off, just limiting the CPU usage won't prevent this attack. For 
example, using very simple tools (i.e. ping and Python scripts), I was 
able to detect the presence of a process using only 50% of only one CPU. 
As long as the adversary has the ability to influence CPU usage, they 
can utilize this covert channel.

 > The cgroup equivalent for a hypervisor is to limit the number of CPUs 
the Tor VM  has access to? (currently one core - on a quad-core system 
that's the 25% limit you recommend)

 > Setting the Tor process to use nice 19 should take care of the ping 
timings you mention?

What I was trying to get at was the idea that we could run everything 
untrusted in a VM, which I creatively call the /untrusted VM/. This 
includes processes such as Tor Browser or Thunderbird or perhaps even 
GPG that perform complex computations on potentially 
adversary-controlled data that would could for distinctive CPU usage 
patterns. Then, we could run a program such as `stress` (available in 
the Debian repositories) with a niceness of +19 in order to force the 
CPU usage on that VM to 100% all the time. Thus, although processes 
running in that VM wouldn't be slowed down by the running instance of 
`stress`, as it's running with a high niceness, they would be unable to 
increase CPU usage at all. This completely thwarts the attack. It might 
be a good idea to limit the VM to 25% CPU to save power.

However, the suggestion of disabling c-states more or less obsolesces 
this suggestion, as the `stress` solution could easily decrease battery 
life by 2-3x, whereas I've never seen wattage even double from disabling 
c-states.

 > Taking into account that some users connect to the clearnet using 
system running Whonix, do these mitigations still hold up?

Unless I've missed something, this shouldn't affect either mitigation 
I've proposed. However, this would put users at risk of a vanilla 
"Load-based Covert Channels between Xen Virtual Machines"-style attack.


To be clear, at this point, I'm leaning towards providing an option in 
Tails and Whonix to disable c-states, perhaps in the form of a GRUB 
entry (this would likely be a very small change in an installation 
script); see [1]. However, I think we wouldn't want to enable it by 
default; I'd guess that most users aren't willing to sacrifice 60% of 
their battery life to prevent this attack.

1. https://access.redhat.com/articles/65410

On 15/07/16 10:37 PM, bancfc at openmailbox.org wrote:
> Hi. Whonix collaborator here. We've given a lot of thought to many 
> types of clock based attacks including the one you are researching so 
> we are interested to know more about how  this applies to our platform.
>
> To run Whonix in KVM please see the relevant steps here [0]. Let me 
> know if you have any further questions on setting it up.
>
>
> Re-adjusting some of the terms you use to apply to VMs:
>
> * Limiting CPU resources for Tor as opposed to the browser component 
> is what counts? (both are separate in the Whonix model)
>
> * The cgroup equivalent for a hypervisor is to limit the number of 
> CPUs the Tor VM  has access to? (currently one core - on a quad-core 
> system that's the 25% limit you recommend)
>
> * Setting the Tor process to use nice 19 should take care of the ping 
> timings you mention?
>
> * Taking into account that some users connect to the clearnet using 
> system running Whonix, do these mitigations still hold up?
>
>
> ***
>
> [0] https://www.whonix.org/wiki/KVM#First_time_user.3F