Don't give remotely exploitable relays the HSDir flag

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

changed milestone to %Tor: 0.2.3.x-final

added component::core tor/tor milestone::Tor: 0.2.3.x-final priority::medium resolution::worksforme status::closed tor-auth type::defect labels

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

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

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.

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

Trac:
Milestone: N/A to Tor: 0.2.2.x-final

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

Trac:
Milestone: Tor: 0.2.2.x-final to Tor: unspecified

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.

Trac:
Status: new to closed
Resolution: N/A to wontfix

Actually, I'm open to the idea.

Trac:
Milestone: Tor: unspecified to Tor: 0.2.3.x-final
Resolution: wontfix to N/A
Status: closed to reopened

Closing this one since #4788 (moved) made it obsolete.

Trac:
Status: reopened to closed
Resolution: N/A to worksforme

Trac:
Keywords: N/A deleted, tor-auth added

Trac:
Component: Tor Directory Authority to Tor

closed

moved to tpo/core/tor#2751 (closed)