Re: [tor-talk] "drop all vulnerable relays from the consensus"

[Roger Dingledine <arma@xxxxxxx>]

On Sun, May 15, 2011 at 10:38:45PM +0200, tagnaq wrote:
> "If someone publishes or demonstrates a code-exec exploit [...] we
> should drop all vulnerable relays from the consensus" [1]
> 
> - Does Tor provide Authority Directories with an easy way to reject/drop
> relays from the consensus based on the platform string or is this only
> possible based on FP or IP?

See tor_version_as_new_as() in routerparse.c.

Then see dirserv.c:

  /* Tor 0.2.0.26-rc is the oldest version that currently caches the right
   * directory information.  Once more of them die off, we should raise this
   * minimum. */
  if (platform && !tor_version_as_new_as(platform,"0.2.0.26-rc")) {
    if (msg)
      *msg = "Tor version is far too old to work.";
    return FP_REJECT;
  } else if (platform && tor_version_as_new_as(platform,"0.2.1.3-alpha")
                      && !tor_version_as_new_as(platform, "0.2.1.19")) {
    /* These versions mishandled RELAY_EARLY cells on rend circuits. */
    if (msg)
      *msg = "Tor version is too buggy to work.";
    return FP_REJECT;
  }

So yes, there's a pretty easy way to do it, just by changing the versions
in those lines (but we haven't made a config option out of it).

> - How will Directory Authorities determine if a relay is "vulnerable"?
> (inspecting the platform string only)?

Yes, along with knowing something about which versions are deployed that
might have modified code. For example, some of the 0.2.1.26 relays out
there are probably running lenny-backports:
http://packages.debian.org/search?keywords=tor
so they're getting patches from our debian maintainer even if the version
isn't changing.

Similarly, most of the 0.2.0.34 and 0.2.0.35 relays on Linux are probably
running from a deb, which received some security backports before Debian
finally dropped support for that version.

And as Sebastian pointed out, some of the relays running 0.2.1.25 are
running from the maint-0.2.1 git branch (and similarly, 0.2.2.19-alpha
might be running maint-0.2.2 git), which are actually more up-to-date
than the versions imply. In the 0.2.2.x case we can check the git revision
in the version if we need to distinguish.

It's really a balancing act here to make use of whatever resources
are volunteered to the Tor network while making relays running old
Tor versions do more good than harm. Cutting out relays reduces the
capacity of the network, making it slower and more frustrating to users
(which could cause them to switch to some other even less safe system),
and reduces the diversity of the network:
https://blog.torproject.org/blog/research-problem-measuring-safety-tor-network

We've made similar tradeoffs in the past between anonymity and
performance. The big example that comes to mind is how we are advertising
higher bandwidth weights for the really fast relays, which improves
performance but reduces diversity.

In my mind the right place to draw the line is to drop relays that are
violating the Tor protocol (e.g. mishandling traffic) in a way that
bites actual users. If we wanted to preemptively drop vulnerable relays,
we should start by identifying crappy operating systems and dropping all
those relays, and then move on to identifying evil countries or telcos
and dropping those relays too -- that way lies madness (or at least a
smaller and weaker Tor network).

--Roger

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