[Date Prev][Date Next][Thread Prev][Thread Next][Date 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@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

--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk