[tor-dev] [tor-talk] Tor Research Framework update

[George Kadianakis]

Gareth Owen <gareth.owen at port.ac.uk> writes:

> Hi all
>
> I thought I'd give you an update on where the Tor Research Framework is now
> at as there's been lots of development over the last few weeks. At present,
> the framework is a largely fully functional tor client with code that is
> easy to read, follow and crucially change for custom functionality.
>
> URL: https://github.com/drgowen/tor-research-framework
>
> Completed
> =======
>
> The examples exercise a big chunk of the functionality so in the examples
> directory, we now have examples on how to do:
>
> - Circuit building, Random circuits based on flags, etc
> - Building HS circuits and establishing streams to their service
> - Consensus parsing examples
> - RELAY_EARLY scanner - scans HSDirs looking for RELAY_EARLYs coming the
> wrong way (aka the recent Blackhat deanon attack)
> - Tor SOCKS Proxy and PortForwarder
>
> The examples are here:
> https://github.com/drgowen/tor-research-framework/tree/master/src/main/java/tor/examples
>
> The RELAY_EARLY scanner took around five minutes to write for example and
> didn't require modifying core library code.
>
> Work in progress
> ==========
>
> Fuzzer: We also have another chap (twilsonb) working on a fuzzing framework
> for Tor that is capable of fuzzing the protocol and directory services -
> although this is at early stage I'm sure he'd welcome help from anyone
> interested.
>

Great! Tor needs better fuzzing :)

I have conducted two activities in this area:

- I once started the ambitious project of making a Tor protocol fuzzer [0].
  I used the Peach fuzzing framework, a decision I later regreted. In
  the end, the fuzzer could successfully fuzz the first few cells of
  the v3 handshake, but I never implemented Tor's crypto which was
  necessary for fuzzing deeper.

  I think there is still lots of value in a fuzzer that can walk the
  various areas of the Tor protocol (circuit building, HSes, etc.) If
  I were to do this now, I would probably write my own networking code
  and only use a premade framework to procuce fuzzed output.

- I used the radamsa mutator [1] and fed Tor tons of mutated
  descriptors, consensuses and hidden service descriptors. This was
  quite fun and effective: within a few hours it found #6811 which was
  a nice crash bug. FWIW, I don't think I ever fuzzed all the various
  directory documents of Tor this way...

  I think this is a fast and easy way of fuzzing the directory part of
  Tor, which has wide parsing attack surface.

Feel free to discuss any aspects of Tor fuzzer development in this
mailing list! (but please send any found 0days to Tor developers in a
confidential manner ;) )

[0]: https://gitorious.org/tor_fuzz/tor_fuzz/source/54105204e91ed2d26e747e10fb21710aecfaf8b3:
[1]: https://code.google.com/p/ouspg/wiki/Radamsa