Gareth Owen gareth.owen@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/...

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/54105204e91ed2d26e747e10fb217...: [1]: https://code.google.com/p/ouspg/wiki/Radamsa