lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <88944.1372550717@turing-police.cc.vt.edu>
Date: Sat, 29 Jun 2013 20:05:17 -0400
From: Valdis.Kletnieks@...edu
To: Neel Rowhoiser <neel.rowhoiser@...look.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: tor vulnerabilities?

On Fri, 28 Jun 2013 23:37:45 -0400, Neel Rowhoiser said:
> I just stumbled across this and despite its sort of half-assed write up, I
> think its possibly an advisory? If I am understanding it correctly, they're
> saying that you can use a directory authority that hands out invalid/wrong RSA
> keys for other relays, you can cause decryption to fail and thus introduce path
> bias to nodes of the directory authorities choosing by selectively handing out
> valid RSA keys?

Oh, it's *that* attack again (as far as I can tell).  Some French guys did a
proof-of-concept a few years ago that you could do this sort of thing if you
subverted a sufficient number of nodes.  But keep reading.

> If the bit towards the end about guard nodes is correct, it would seem to
> indicate that they can use the semantics for detecting when a guard is causing
> too many extend relay cells to fail to cause valid guards to be marked invalid,
> and their rogue guards to succeed essentially using tor's semantics against
> them and causing the odds that you-re ingress point to the tor network is rogue
> to approach 1.

The problem is that you have to subvert a large number of relays to
do it, in a way that doesn't get noticed..

> Why aren't the tor relay keys signed? And what other myriad of documents do

And who would sign said relay keys?  They're all essentially self-signed
already, so what you're looking for is a PKI.  And the whole point of the tor
system is that nobody involved trusts a central authority.  If you've got a
good idea on how to do it, feel free to comment.

> directory authorities serve that also don't have integrity controls? This sort
> of makes me question the tor projects ability to deliver on any of the promises
> they make, as it would seem that a person needs like 3 or 4 rogue nodes before
> they could start de-anonymizing users, and the more of them they introduced the
> more of the network they could capture?

Actually, it's more like 3 or 4 *hundred* nodes.  As I write this, there
are 3,903 relays connected, 1,218 guard nodes, and 2,396 directory mirrors.

http://torstatus.blutmagie.de/

Even if you control 400 of those routers, the odds that any connection will
only traverse your nodes is only 0.1% or so.  If you have "3 or 4', it's
literally a one-in-a-billion shot.  Assuming a million tor tunnels form a
day, you'd catch one circuit every 3 years or so.  And no guarantee that
the circuit you caught carried anything you would find useful.

I suppose you could bring up 4,000 tor nodes of your own, to increase your odds
of end-to-end control on a circuit all the way to 12% or so. However, that's
very much a one trick pony, and probably wouldn't work simply because people
would notice the sudden growth before you got enough nodes connected to do much
damage.

And using rogue directory servers to improve your odds doesn't help either.
Currently, there's a whole whopping 5 'bad exit' routers.  You can improve
your chances by corrupting stuff so half the exits are bad - but again, that
will get noticed when a single-digit number hits three digits.  And you need
to get it up to 4 digits before you have decent odds.

And yes, the Tor designers are totally aware that this "vulnerability"
exists - the problem is that all proposed solutions so far are even
worse (for instance, requiring signed relay keys).


Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ