[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

Hash: SHA1

Also, forgot to add: I also posted this on my blog [1]. As well, PGP signature so I can properly claim this later.

1. https://ethanwhite.xyz/cpu-correlation
Version: GnuPG v1


On 15/07/16 11:18 AM, Ethan White wrote:
I recently had an idea for using CPU load covert channels for practical deanonymization attacks. After using them to deanonymize myself multiple times, I conferred with some Tor Project people, and they recommended I post it here.

*# Covert Channels*

A _covert channel_ is any technique that allows two programs to communicate that should be unable to communicate; for example, encoding information in TCP initial sequence numbers, as in [1], or in the timings of HTTP requests (imagine: a request on an even numbered second is a 0; a request on an odd-numbered second is a 1).

An example use case for a covert channel is to communicate an IP address from outside an anonymized context to within
one, or vice versa.

*# CPU Load Covert Channels*

A _CPU load covert channel_ is a specific covert channel based on the use of CPU load as a means of transmission.

An example of a CPU load covert channel is as follows: we have two processes, which we wish to communicate; one is designated as the _sender_ or _transmitter_, while the other is designated as the _receiver_. The receiver is constantly running a loop (that normally takes about 1 second), and recording the timings; the transmitter runs the same loop to transmit a 1, and does nothing to transmit a 0. On a single-core machine, the receiver will observe that the loop will take about twice as long when the sender is transmitting a 1 as when it isn't. On a multicore machine, the
transmitter can use one thread per logical core.

CPU load covert channels are not new; see, for example, [2], which used them to transmit data between Xen domains. However, I believe that more though needs to be put into how these affect Tor.

I've actually put together a demo of this to transmit an IPv4 address from a regular, non-anonymized browser to Tor Browser or similar [4]. For me, at least, this seems to work nearly 100% of the time, with nearly 100% accuracy; I
also find it fun to watch a CPU usage graph while this is running.

*# Timings of ICMP PING packets*

Given only the above, and certain assumptions about the Tor client, it would still be safe to use an operating system such as Tails that does not allow most applications to learn the real IP address. However, there are more ways to observe CPU load than via running code on the same computer. For example, in [3], Murdoch et al. show that the increased heat emitted by a CPU when it is running under high load can cause the clock on the motherboard to skew by a very small amount,
thus allowing one to judge its CPU usage from afar.

With two computers connected via Ethernet through a switch, I would normally get ping timings of around 250 microseconds. However, when the computer being pinged was pegged at 100% CPU on all cores, _ping latency would drop to about 170 microseconds._ This could be observed over a larger distance, such as through a Wi-Fi network (think Internet café), by averaging
over a large number of samples.

I was able to use this to transmit a 32-bit IPv4 address from Tor Browser on Debian to a Python script running on a separate computer (Linux Mint, if it matters), with _only four bit errors_, easily within the reach of error correcting codes. As far as I know, this is the first time this particular property has been used as a covert channel; if I'm wrong, contact me, and I'll correct it. I also believe that this would work if one computer was running Tails or Whonix, but
they're both a pain to set up, so I haven't tested with them yet.

*# Mitigations*

*## Communication between an anonymized and non-anonymized browser**through loop timings*

The most obvious way to fix this is using cgroups to limit the CPU usage of any given browser to only a fraction of the total available resources; if two concurrent loops are limited to 25% of the CPU, then they should (in theory) be unable to notice eachother. Although this would be a nice start, there may be ways to get around this. (If we were to do this, it may be more profitable in the long-term to actually run Tor Browser within Docker.)

*## Ping timings*

This one seems harder to mitigate. However, we should be able to use a similar trick: containerize Tor Browser, but instead of simply limiting the CPU usage to 25%, _ensure that the CPU usage is always precisely 25%_; this could be implemented using a process with a niceness of 19 running in an infinite loop. This would mean that CPU usage would be constant, even if Tor Browser were itself using more CPU time, thus (in theory) preventing the ping latency side channel.

Just disabling ping packets (or all of ICMP for that matter) isn't enough. As an example, an attacker could observe the timings of TCP SYN-ACK or ACK packets (those are used during TCP's 3-way handshake). One suggestion would be to ensure that all packets are always sent precisely on the millisecond. However, depending on the precise mechanism for the
decreased ping latency, this may not help at all.

*# Acknowledgements*

I would like to thank Jonathan Huo for allowing me to bounce ideas off him, and Stephen J. Murdoch and Georg Koppen for
their help in developing the idea.

*# Footnotes*

1. Murdoch, Steven J., and Stephen Lewis. "Embedding covert channels into TCP/IP." International Workshop on Information Hiding. Springer Berlin Heidelberg, 2005. (http://www.gray-world.net/es/papers/ih05coverttcp.pdf) 2. Okamura, Keisuke, and Yoshihiro Oyama. "Load-based covert channels between Xen virtual machines." Proceedings of the 2010 ACM Symposium on Applied Computing. ACM, 2010. (You have to pay for this paper; sorry.) 3. Murdoch, Steven J. "Hot or not: Revealing hidden services by their clock skew." Proceedings of the 13th ACM conference on Computer and communications security. ACM, 2006. (https://www.gnunet.org/sites/default/files/HotOrNot.pdf) 4. https://www.ethanwhite.xyz/static/2f3085649a61f451fd9692e891a33958/index.html

Also, unfortunately, I'm going to be away from all things internet for the next week or so, and thus unable to answer many
questions. Sorry for essentially commiting and leaving.

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to