Re: [tor-talk] FBI cracked Tor security

[Mirimir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/15/2016 05:46 PM, Joe Btfsplk wrote:



> Many of things mentioned in "what else you need to remain
> anonymous" type articles - don't use Flash, plugins, file sharing,
> etc., are easy. It's all the other things that can go, or are,
> wrong that most people wouldn't understand.  For years, Tor devs
> weren't even sure how to report TBB screen size & many other
> unresolved issues.  I filed various bugs on many things, but had no
> idea how to fix them.   How can even advanced users be expected to
> fix these & more problems when it sometimes takes extremely
> talented Tor devs years to find solutions? Again, a pipe dream.

Such as, some TLA drops malware that phones home, and there's nothing
to stop it.

Just use Whonix :)



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJXianAAAoJEGINZVEXwuQ+hJEH/0KznKtJwbE6GOxvQ8eVJbfi
5MI8NtW9y5SG+hY/yeHBA7hpo0yj4FT59caYWDMgUlghg8JJPMt4x6kvmhKLMa6r
euUtTd4FlMRyJLPlis8V8Itw0OfK3ch1Ipkj4qbcenNUD6/0PKxMx7gLVESHyHyA
vR2+oB84NB3gYGI76H5tI5NZM5I4gb1YmEeOEinunEN8ALXLdZ/JnRc2B95MoSYs
wCJifYpjs2rBiLCX5fDM8JKbeTKFJkf7yb7vSvw5CY7vXcG0pux+7b32H1/Z9ScI
wOS9Vyz+NOTW087cNSu8O4/Pket5m6JyOSCDaxgKO7QgOwoUKwrEzUqgZiPkInQ=
=NVXB
-END PGP SIGNATURE-
-- 
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

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

[bancfc]

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

Re: [tor-talk] FBI cracked Tor security

[Joe Btfsplk]

On 7/15/2016 12:34 AM, Jon Tullett wrote:

On 15 July 2016 at 01:23, Joe Btfsplk  wrote:

On 7/14/2016 2:34 PM, Jon Tullett wrote:

Thanks Jon.  I agree w/ most that you said.  Again, semantics. Whether they
cracked Tor or Tor Browser won't change if the brutal dictator has you shot
in the front or back of the head. :)

Again, remember that this conversation was in the context of Freedom Hosting.

Absolutely agree that the same style of investigation could (and
probably does) happen in a more brutal political regime. Users there,
being at greater risk, have a greater need to take further steps to
protect themselves.



Unless one is using Tor w/ their own internet browsing application, an
exploited weakness in Tor Browser - modified Firefox - has the same effect
on users.  They're a package deal.

Well, no. Tor does make it clear you need to do more than just
downloading TBB to be anonymous and secure. If you think TBB is a
single-solution prepackaged silver bullet, you are at risk.

I don't think there's any debate whether Tor should try to be such a
silver bullet - clearly it can't and shouldn't - the question seems to
be around whether Tor should give more clear guidance/warnings. I'm
always in favour of that.



You're not really suggesting that users under hostile dictatorships or ones
trying to expose democratic government unconstitutional actions,  take full
responsibility for the ongoing modifying, patching & constant reading about
weaknesses of Tor Browser "for their own security?"

Yeah, I kinda am. Users in such hostile environments absolutely need
to take more care to keep themselves secure, and not just online. If
you are relying on any product to keep you alive, you definitely
should be constantly reading about it.
Respectfully, you're dreaming if you think whistle blowers, political 
activists or citizens under brutal regimes are *necessarily,* or even 
mostly computer geeks. :)
You may be correct that only very advanced geeks or (sane) persons w/ 
unlimited access to one, _should_ use TBB in dangerous situations, if 
they don't understand every detail about what can go wrong & how to fix 
it themselves.


Very few people meet those criteria.  I don't  & I've been studying Tor 
& TBB for yrs.   People that might have interests in whistle blowing or 
activism, *also* having the knowledge & ability to troubleshoot, modify 
or patch TBB on an ongoing basis are almost nil.  Except for those w/ no 
concept of the extreme risk they're taking, that leaves very few people 
to do any blowin' or activatin'.   People under brutal regimes don't 
need to be activists to have a real need for reliable anonymity (no 
unpatched browser bugs).  They just need to safely access info besides 
governmental propaganda or to pass info to similar minded persons.  Do 
we think they're all going to be coders that can patch browsers?  That's 
a dream.  :)


If the only people (in dangerous situations) that should use Tor / Tor 
Browser are geeks, it doesn't have a very wide audience. Regardless of 
whose job it is to make something like TBB "as secure as possible," 
there just aren't many people like E. Snowden w/ extreme computer talent 
- to do what you're suggesting -  & desire (possibly stupidity) to go 
after top officials or their government.


Many of things mentioned in "what else you need to remain anonymous" 
type articles - don't use Flash, plugins, file sharing, etc., are easy.  
It's all the other things that can go, or are, wrong that most people 
wouldn't understand.  For years, Tor devs weren't even sure how to 
report TBB screen size & many other unresolved issues.  I filed various 
bugs on many things, but had no idea how to fix them.   How can even 
advanced users be expected to fix these & more problems when it 
sometimes takes extremely talented Tor devs years to find solutions?  
Again, a pipe dream.


The sage advice under "List of Warnings:"  "Ultimately the best 
protection is a social approach: the more Tor users there are near you 
and the more diverse  
their interests, the less dangerous it will be that you are one of 
them."  L I'll B.  Unless sites you're visiting  or your exact ISP 
server are known to have 100's of TBB users - at once, that doesn't help 
much.


I'm not too sure about trusting one's life to a system based in part on 
pure guesstimating how many entry & exit relays are enemy controlled.  
Calculating statistical odds of being identified, based on unknown of 
numbers of enemy controlled nodes; the number of times & frequency entry 
guards change, number of sites visited, etc. :D








That Tor Project is saying Tor is relatively anonymous; as for Tor Browser,
everyone's on their own.

It's saying that the Tor network will help you stay anonymous, and the
browser bundle will help facilitate that, but you also need to take
further steps to stay anonymous and secure. I think that's realistic
and 

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

[Roger Dingledine]

On Fri, Jul 15, 2016 at 11:18:38AM -0400, Ethan White wrote:
> 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.

Neat! Hopefully that away-from-the-net part means you'll be at PETS in
Darmstadt? If so, many of us will be there too, and we'll be excited to
talk to you -- and you should be sure to sign up for a rump session slot
too. If not, that's sad because PETS is the perfect place for talking
more about these topics. :)

For the ping timing channels in particular, see also Nikita's paper
about that from long ago:
http://freehaven.net/anonbib/#remote-traffic-pets12

--Roger

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

Re: [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 

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

[Ethan White]

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