[tor-bugs] #24031 [Core Tor/Tor]: Protover.rs could use a better algorithm

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Mar 14 22:12:52 UTC 2018

#24031: Protover.rs could use a better algorithm
 Reporter:  nickm                   |          Owner:  isis
     Type:  defect                  |         Status:  accepted
 Priority:  High                    |      Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor            |        Version:
 Severity:  Normal                  |     Resolution:
 Keywords:  rust 033-must protover  |  Actual Points:
Parent ID:                          |         Points:  1
 Reviewer:                          |        Sponsor:

Comment (by isis):

 Replying to [comment:5 nickm]:
 > (FWIW, I think it would be okay to defer this to 0.3.4 if it isn't fast.
 We can just say "don't use Rust on dirauths yet", right?)

 I think it really does matter to get it in, even if we advise dirauths
 against using Rust, due to the potential for DoS that teor mentioned.
 Wouldn't the attack vector look something like this?:

 1. A bad relay with alternate/modified tor implementation says `Link
 1-65536,LinkAuth 1-65536,Relay 1-65536,HSIntro 1-65536,HSRend
 1-65536,HSDir 1-65536,DirCache 1-65536,Desc 1-65536,Microdesc 1-65536,Cons

 2. The dirauths parse that in C and allow it.

 3. A Rust relay/client gets this consensus and suddenly it's got a HashSet
 with 10 keys, each one with 65536 32-bit integers in it, so that's
 2560.8594 kilobytes allocated per relay that does this. (according to this
 [XXX this tiny rust program])

 4. Bad relay operator spins up ~400 relays and suddenly every Rust-enabled
 relay/client in the network is using over 1 GB of memory.

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24031#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tor-bugs mailing list