Hi George
Thanks for your reply and information+links. Tim (cc-ed) is leading the work on the fuzzer and is looking at a couple of different frameworks. I've set up a example that can do port-forwarding to a BEGIN_DIR service - so you can just point a fuzzer at the local port - this opens up a wider range of potential targets (some paths on the directory service are over Tor only) .
The framework implements the tor protocol so should be easy to modify to do fuzzing of the actual protocol but I'm skeptical how successful this would be, I can only think of a couple of places that could be error prone.
Looking through the source, I agree that there's a very large surface area and also there's a lot of manual string manipulation which is potentially error prone. It's reassuring that you've already found bugs this way, it suggests the route isn't a complete dead-end.
I've cc-ed Tim, so he might pick your brains !
Thanks Gareth
On 11 August 2014 18:19, George Kadianakis desnacked@riseup.net wrote:
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 ;) )
: [1]: https://code.google.com/p/ouspg/wiki/Radamsa
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev