[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Practical deanonymization using CPU load covert channels
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@xxxxxxxxxxxxxxx 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
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk