Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#2751 closed defect (worksforme)

Don't give remotely exploitable relays the HSDir flag

Reported by: rransom Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-auth
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

2011-03-13 23:27 <hsdir> why relays with heap corruptions still have hsdir? it is way to crash for them and lost some number of hsdir for net.

Child Tickets

Change History (12)

comment:1 Changed 8 years ago by Sebastian

I don't think I agree here. If we believe those relays can't store hsdirs they surely can't handle client traffic either, in which case we should cut them out of the network entirely, or we decide they are ok to keep and we keep them hsdirs too

comment:2 in reply to:  1 ; Changed 8 years ago by rransom

Replying to Sebastian:

I don't think I agree here. If we believe those relays can't store hsdirs they surely can't handle client traffic either, in which case we should cut them out of the network entirely, or we decide they are ok to keep and we keep them hsdirs too

It's much easier to crash those buggy relays than to run arbitrary code on them. Some attackers have greater incentive to crash HSDir relays (in order to censor certain hidden service descriptors) or to crash Guard relays (in order to force a particular client whose guard nodes are known to choose another Guard node) than to crash arbitrary other relays.

If someone publishes or demonstrates a code-exec exploit for one of the heap-corruption bugs, we should drop all vulnerable relays from the consensus, but until then, we only need to take away the flags (Guard and HSDir) that make crashing a relay particularly harmful to the Tor network (and/or beneficial to an attacker).

comment:3 in reply to:  2 ; Changed 8 years ago by arma

Replying to rransom:

but until then, we only need to take away the flags (Guard and HSDir) that make crashing a relay particularly harmful to the Tor network (and/or beneficial to an attacker).

This is another of those cases where we have a tradeoff to make: increased robustness (or anonymity in the case of Guard flags) against passive adversaries, vs decreased robustness against a particular (currently hypothetical) active adversary.

If we had more time to pay attention, I would say we should keep an eye out for this attack, and if we see it in the wild, then drop the flags. If we don't see it, no point reducing diversity against all the other (hypothetical) attackers we can't observe.

But if we don't have time to pay attention, should we reduce the diversity of the network preemptively? Sure makes me wish I had more answers to
https://blog.torproject.org/blog/research-problem-measuring-safety-tor-network

How many such relays are we talking about? As we wait, both the risk of keeping them and the impact of dropping them become less.

comment:4 in reply to:  3 Changed 8 years ago by nickm

Replying to arma:

How many such relays are we talking about? As we wait, both the risk of keeping them and the impact of dropping them become less.

Not easy to say given how distributors sometimes apply patches. But here's what the relays in the current consensus claim to be:

[506]$ grep '^v ' ~/.tor/cached-consensus  | sort -n | uniq -c 
   2 v Tor 0.2.0.31 (r16744)
   2 v Tor 0.2.0.32 (r17346)
   1 v Tor 0.2.0.33 (r18212)
  21 v Tor 0.2.0.34 (r18423)
  19 v Tor 0.2.0.35
  18 v Tor 0.2.1.19
  10 v Tor 0.2.1.20
  10 v Tor 0.2.1.21
  25 v Tor 0.2.1.22
   3 v Tor 0.2.1.23
   4 v Tor 0.2.1.24
  46 v Tor 0.2.1.25
 207 v Tor 0.2.1.26
   5 v Tor 0.2.1.26 (r7998a25fc4bfbf47)
  12 v Tor 0.2.1.26 (r7f4f5a379d6e56c3)
   9 v Tor 0.2.1.26 (rbde5a11c51433a6e)
   7 v Tor 0.2.1.26 (rc448fc5cb99188ea)
  18 v Tor 0.2.1.27 (r5e842d29f970dcaa)
  45 v Tor 0.2.1.27 (re57cb6b9762a2f94)
   1 v Tor 0.2.1.28 (r211)
  11 v Tor 0.2.1.28 (r60ccf2b5f1ac7f66)
   2 v Tor 0.2.1.28 (r62)
  67 v Tor 0.2.1.28 (r6e5496a2407ee589)
 247 v Tor 0.2.1.29 (r318f470bc5f2ad43)
 552 v Tor 0.2.1.29 (r8e9b25e6c7a2e70c)
 153 v Tor 0.2.1.29 (r98a499a5377f18b1)
 684 v Tor 0.2.1.30
   3 v Tor 0.2.2.10-alpha
   2 v Tor 0.2.2.12-alpha-dev
   8 v Tor 0.2.2.13-alpha
  20 v Tor 0.2.2.15-alpha
   3 v Tor 0.2.2.17-alpha
   2 v Tor 0.2.2.18-alpha
  18 v Tor 0.2.2.19-alpha
   8 v Tor 0.2.2.20-alpha
  21 v Tor 0.2.2.21-alpha
 149 v Tor 0.2.2.22-alpha
  89 v Tor 0.2.2.23-alpha
   1 v Tor 0.2.2.6-alpha
   1 v Tor 0.2.2.8-alpha
  10 v Tor 0.2.3.0-alpha-dev

comment:5 Changed 8 years ago by nickm

Milestone: Tor: 0.2.2.x-final

comment:6 Changed 8 years ago by arma

There are now fewer risky relays, but still plenty (especially running 0.2.1.26).

I think we should send mail to these operators and encourage them to upgrade.

The root problem here is that people are still running vulnerable versions. That's the problem we should try to fix (and not just hack around).

comment:7 Changed 8 years ago by rransom

Milestone: Tor: 0.2.2.x-finalTor: unspecified

comment:8 Changed 8 years ago by Sebastian

Resolution: wontfix
Status: newclosed

I'm closing this, as we don't seem to want to do what the ticket suggests. Getting people to upgrade is part of our other bundle plans.

comment:9 Changed 8 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.3.x-final
Resolution: wontfix
Status: closedreopened

Actually, I'm open to the idea.

comment:10 Changed 7 years ago by arma

Resolution: worksforme
Status: reopenedclosed

Closing this one since #4788 made it obsolete.

comment:11 Changed 7 years ago by nickm

Keywords: tor-auth added

comment:12 Changed 7 years ago by nickm

Component: Tor Directory AuthorityTor
Note: See TracTickets for help on using tickets.