[tor-commits] [tor/release-0.2.2] Try to clarify impact of bug 6537

nickm at torproject.org nickm at torproject.org
Fri Aug 3 17:42:02 UTC 2012


commit d48cebc5e498b0ae673635f40fc57cdddab45d5b
Author: Nick Mathewson <nickm at torproject.org>
Date:   Fri Aug 3 11:54:11 2012 -0400

    Try to clarify impact of bug 6537
    
    I don't personally agree that this is likely to be easy to exploit,
    and some initial experimention I've done suggests that cache-miss
    times are just plain too fast to get useful info out of when they're
    mixed up with the rest of Tor's timing noise.  Nevertheless, I'm
    leaving Robert's initial changelog entry in the git history so that he
    can be the voice of reason if I'm wrong. :)
---
 changes/pathsel-BUGGY-a |   16 +++++++++-------
 1 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/changes/pathsel-BUGGY-a b/changes/pathsel-BUGGY-a
index cad2af5..2e642c7 100644
--- a/changes/pathsel-BUGGY-a
+++ b/changes/pathsel-BUGGY-a
@@ -3,10 +3,12 @@
     - Try to leak less information about what relays a client is
       choosing to a side-channel attacker.  Previously, a Tor client
       would stop iterating through the list of available relays as
-      soon as it had chosen one, thus leaking information about which
-      relays it picked for a circuit to a timing attack.  (Tor is
-      likely to still leak information about which relays it has
-      chosen for a circuit to other processes on the same computer,
-      through e.g. which cache lines it loads while building the
-      circuit.)
-
+      soon as it had chosen one, thus finishing a little earlier
+      when it picked a router earlier in the list.  If an attacker
+      can recover this timing information (nontrivial but not
+      proven to be impossible), they could learn some coarse-
+      grained information about which relays a client was picking
+      (middle nodes in particular are likelier to be affected than
+      exits).  The timing attack might be mitigated by other factors
+      (see bug #6537 for some discussion), but it's best not to
+      take chances.  Fixes bug 6537; bugfix on 0.0.8rc1.





More information about the tor-commits mailing list