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

[Ethan White]

-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXiQB5AAoJEBUjAvV7iUrG9zcQAINscd6NtoNCHcn6qgbOc+3/
4qQhlsK3hyAvnA9rqfLSJJr+bAhpqdjubsNGK+vWmxKLNSU7Lz/aazNAEyShfuuw
wGIm7ntgWVnoJXFWdtq8gDKLDqRtVK+F6tvrvvafPrSUx8G9y0hhJkgf/PFNhIvH
d9XMsIHxyyB5KwQbEhz5ALA9ymMwbvFY4pO35pO0Gd/Clyn1ayMm87OF0YYVNMs7
W+KrQVENrjr7l3jEsSY+QSdxvVThwhrGRTA7ST2DLXdmtgM4Axm+u2vBvl2u25TX
JzRMhVvlDMZe/awkLcks0BhL0jyRZUXyx409aKf4K+umZ/Z47PwywQQ5tkiI6qhr
6hPCZ/Ewm7lWw7naGDJiPQrt6slcAgERaRe1AWfdNnAdZYtfMnbPb0cWNK6KaPlV
RFhrxtm6axMcOPi1O7+lBhunhIg8XcWtE4+wTOM9HkYtRovsnBzvZdwSXZPKXrfU
JrrSzCncCS6vM9Jfg9GamYBidTTRA7LRsqTNcqmNHMsCdeicAv5ts/iqWj9CIKlW
2Vb2Ep1mxBdqmjKR7/+xz4WRQSI6ge74g2j1tS7wAKBdagTJadl1XJ5/9Z+5uDFt
h/W7Owx1WSf/4ioc8a8zxHdc5J3gaO8HrYhSskqxmQ4loHD6a77O7a2Ssay2JAAU
FjbO71xWD+4hWwRAyNfd
=9Rfq
-----END PGP SIGNATURE-----

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