Re: [tor-dev] CVE-2020-8516 Hidden Service deanonymization

[Mike Perry <mikeperry@xxxxxxxxxxxxxx>]

On 2/6/20 5:54 AM, George Kadianakis wrote:
> 
> David Goulet <dgoulet@xxxxxxxxxxxxxx> writes:
> 
>> On 04 Feb (19:03:38), juanjo wrote:
>>
>> Greetings!
>>
>>> Since no one is posting it here and talking about it, I will post it.
>>>
>>> https://nvd.nist.gov/vuln/detail/CVE-2020-8516
>>>
>>> The guy: http://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html
>>>
>>> Is this real?
>>>
>>> Are we actually not verifying if the IP of the Rend is a node in the Tor
>>> network?
>>
>> We (network team) actually don't think this is a bug but it is actually done
>> on purpose for specific reasons. Please see asn's answer on
>> https://bugs.torproject.org/33129 that explains why that is.
>>
>> Onto the bigger issue at ends that the post explains. I'm going to extract the
>> relevant quote that this post is all about:
>>
>>     Remember: the guard rarely changes but the other two hops change often.
>>     If he can repeatedly map out my circuit's last node, then he can build a
>>     large exclusion list. If he can exclude everything else, then he can find
>>     my guard node. And if he can't exclude everything, then he can probably
>>     whittle it down to a handful of possible guard nodes.
>>
>> That is indeed a known attack. One can create a set of relays from the 3rd
>> node (last one before connecting to the rendezvous point) selected by the
>> service and doing enough requests to the service, you can end up with a very
>> large set of relays that can _not_ be your Guard due to how path selection
>> works as explained in the blog post.
>>
> 
> For what it's worth, I'm glad this discussion has been restarted because
> we did lots of research work in 2018 about these sort of attacks, but we
> were kinda drown in the various tradeoffs and ended up not doing much
> after releasing the vanguard tool.
> 
> For people who are following from home and would like to help out here
> is some reading materials:
>    https://lists.torproject.org/pipermail/tor-dev/2018-April/013070.html
>    https://lists.torproject.org/pipermail/tor-dev/2018-May/013162.html
>    https://trac.torproject.org/projects/tor/ticket/25754
> 
> Basically, from what I remember, to defend against such attacks we
> either need to change our path selection logic (#24487), or abandon the
> path restrictions that cause infoleaks (big thread above), or use two
> guards (prop#291 plus big thread above). Each of these options has its
> own tradeoffs and we need to analyze them again. If someone could do a
> summary that would be great to get this started again...
> 
> For now, if you are afraid of such attacks, you should use and love vanguards!

Yes, specifically vanguards always uses two guards and disables all path
restrictions to mitigate info-leak route disclosure attacks like the above.

Vanilla Tor uses two guards only sometimes, and that is part of the info
leak. Using two guards is not enough by itself, though, for cases where
you get unlucky and choose both guards from the same Family or some
other restriction violating case that will leak info by way of making it
clear which relays you *don't* use for your 3rd hop.

Since MyFamily and the other path restrictions are of questionable
value, but the info leak from using path restrictions is clear and
measurable, we opted to make the tradeoff to disable path restrictions
entirely in the vanguards addon. This is actually done by the
HSLayer*Nodes torrc options that we use. It was significantly less
disruptive to disable path restrictions only if those options were set,
than to redo all path selection in Tor itself. See the parent ticket and
its children for details:
https://trac.torproject.org/projects/tor/ticket/25546

I filed https://github.com/mikeperry-tor/vanguards/issues/53 to make
these choices clear in the vanguards docs. Right now you have to read
the tor manpage for the torrc options we used in order to even know
about these choices, which is not great.


The creation vanguards addon itself was also somewhat controversial -
asn and I basically had to go rogue to get all of these defenses
prototyped in a reasonable time frame. Merging these defenses into Tor
is a significantly larger engineering task than making a python control
port addon.

It is rather sad that we have to make such choices for security
features/improvements like this, and for the tagging problem. But
security features are surprisingly difficult to obtain funding for (!),
and so we often have to find ways to do whatever we can in these areas.

-- 
Mike Perry

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev