CVE-2016-5696 and its effects on Tor | Hacker News Reader

CVE-2016-5696 and its effects on Tor

blog.patternsinthevoid.net

64 pointsashitlerferad13 comments

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?

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.

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.

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.

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.

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

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

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

https://blog.patternsinthevoid.net/static/images/2015/12/car...

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

https://github.com/torvalds/linux/commit/75ff39ccc1bd5d3c455... is the patch. Linus is credited with the suggestion.

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

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.

Reply on news.ycombinator.com