
CVE-2016-5696 and its effects on Tor - ashitlerferad
https://blog.patternsinthevoid.net/cve-2016-5696-and-its-effects-on-tor.html
======
russell_sears
I read this explanation a few times, and am afraid I still don't understand
why Tor is not vulnerable to this attack. Let's say I'm an attacker that
provides enough bandwidth to compromise N% of client circuts, and I can
disrupt non-compromised circuits at will. Casuing clients to repeatedly
renegotiate non-compromised circuits lets me compromise >>N% of circuits,
right? For small N, the chance of getting a compromised circuit is roughly
linear in the number of circuit disruptions, right?

Unless I'm missing something, this vulnerability provides a significant
multiplier to existing Sybil attacks against Tor. A quick search suggests
there have been Sybil attacks in the past.

Am I missing something obvious here?

~~~
zmanian
This attack is a general amplifier on denial of service attacks on Linux
server.

If this attack was deployed against Tor, this would appear as a general DDOS
attack against Tor and degrade most users experience.

It would not help an attacker direct circuits towards a malicious exit as
described in the paper.

~~~
russell_sears
I still don't understand how you come to the conclusion that the attack won't
work.

The bolded text in the blog post reads "the middle relay will pick a different
exit relay", and should read "the client will pick a new circuit at random
using the same bandwidth-proportional weights."

The security properties of the corrected description aren't very comforting:
the attack is no longer guaranteed to work, just like there is no guarantee I
will ever roll a one with a fair die.

~~~
zmanian
You'll get an exit with DDOS attack against it. Not an exit controlled by the
attacker. The attacker will see the same fraction of Tor traffic with or
without the attack. The Tor user base will notice a massively degraded
experience.

You can't affect the proportion of Tor traffic that flows through a given exit
with a DDOS attack.

~~~
thegeomaster
I think the parent comment is saying that given an attack which can reliably
abort connections between two arbitrary endpoints, one can reliably break
other users' Tor circuits, which causes their Tor clients to renegotiate new
ones. If a circuit is negotiated such that all nodes are owned by the attacker
(in which case the attacker can unmask the affected user), the attacker can
then choose not to disrupt that particular circuit. This, in turn, enables the
attacker to penalize non-attacker-controlled circuits, and cause Tor clients
to settle on compromised ones (which won't be penalized). This gives the
attacker more power than simply waiting for an unlucky client to build a
circuit with all nodes belonging to the attacker.

If this is indeed what the parent is saying, and if I'm understanding the
attack and the Tor protocol correctly, I too don't see why such an attack
isn't feasible. I'm perhaps in the wrong and missing something, but would very
much appreciate if someone could clear this up for me.

~~~
belorn
> enables the attacker to penalize non-attacker-controlled circuits, and cause
> Tor clients to settle on compromised ones

That's the key question. Will clients "settle" on compromised ones, or just
continue to try access the penalized (dead) circuits?

A few years ago, there were a bug which was used to rapidly force users to
create new paths. The Tor Project fixed that bug, but they also added a extra
precaution for future bugs by limiting how new paths were selected in regard
to guard nodes. As to my understanding, when a client first connects, it
initially generate a random (but consensus weighted) subset selection of all
guard nodes. It then randomly picks one from that selection when creating new
paths, which mean that only guard nodes in the selection can ever be picked by
the client. A client that is attacked as described in the article will just
cycle through its lists indefinitely and never choose a compromised node,
unless it already picked a compromised node initially.

~~~
thegeomaster
Ah, I see. Thanks for explaining that so clearly!

------
joshumax
Did anyone else click on the image and get redirected to this?

[https://blog.patternsinthevoid.net/static/images/2015/12/car...](https://blog.patternsinthevoid.net/static/images/2015/12/card.jpeg)

~~~
sowellz
I noticed this as well, what I cant figure out is if it was an accident or
not?

------
nullcipher
[https://github.com/torvalds/linux/commit/75ff39ccc1bd5d3c455...](https://github.com/torvalds/linux/commit/75ff39ccc1bd5d3c455b6822ab09e533c551f758)
is the patch. Linus is credited with the suggestion.

------
ivan_ah
If only all technical communication were as clear as this blog post... great
explanation.

~~~
goodplay
I personally found it too informal; I found the numerous non-technical remarks
about how "boring" TCP off putting, tbh.

That said, I understand that the author added these in an attempt to make the
article more enjoyable. I also appreciate the fact that some readers will
indeed find these additions enjoyable. To each his own.

