Great! Tor needs better fuzzing :)Gareth Owen <gareth.owen@xxxxxxxxxx> 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.
>
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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev