[tor-dev] [tor-talk] Tor Research Framework update
gareth.owen at port.ac.uk
Mon Aug 11 18:47:49 UTC 2014
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 !
On 11 August 2014 18:19, George Kadianakis <desnacked at riseup.net> wrote:
> 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
> > at as there's been lots of development over the last few weeks. At
> > 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:
> > 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
> > 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 .
> 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  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 ;) )
> : https://code.google.com/p/ouspg/wiki/Radamsa
> tor-dev mailing list
> tor-dev at lists.torproject.org
Dr Gareth Owen
School of Computing, University of Portsmouth
Tel: 02392 846423
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev