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

Hi George,

I'm still trying to work out exactly how to go about fuzzing Tor. So far, I've been to defined an initial problem space, configured a test environment, and explored some fuzzing libraries / tools.

Fuzzing Problem Space

We started by looking at fuzzing Tor directory download requests over HTTP. This seemed like a manageable initial chunk of work.

I sketched an early draft design[0], and developed an annotated grammar for Tor directory requests[1] based on the Tor directory spec[2].

Configuring a Test Environment

I created scripts and configuration files to build, run and monitor a local-only tor directory cache.[3] I configured hardened, typical, and feature-full builds, all with dmalloc to catch memory access errors. I plan to start testing on the feature-full build, then re-test failures against the builds with smaller surfaces.

Exploring Fuzzing Tools / Libraries

JBroFuzz[4] is a HTTP / browser fuzzer written in Java. (tor-research-framework is also written in Java.) It focuses on exhaustive iteration through a set of alternatives.

I anticipate using JBroFuzz as a library to generate correct and near-correct requests to a tor instance. It may also be useful interactively, although the included analysis / graphing tools didn't work in my build. (And it's listed as "inactive".)

Thanks for the pointer to radamsa[5], it looks like it's much more structure-aware than many of the other black-box fuzzes I've looked at. I could imagine using radamsa to mutate correct requests on their way to tor. (JBroFuzz isn't designed to do random mutation.)

I've also looked at at zzuf[6], which appears unloved, but is incorporated into the CERT Basic Fuzzing Framework[7]. The set of zuff/BFF mutations is limited to bit-level flips, and isn't syntax-aware. Hooking into all the target process' file descriptors is neat, but it requires a local(-only) process to fuzz.

Results

Certain parts of directory request URLs get written to the tor debug log unescaped.[8] But the effect is severely limited: it simply makes reading the log in a terminal irritating (including BEL, DEL, and CR effects - the BEL effect was how I discovered the issue).

Further Work

These are the tasks I can think of:

1. Write JBroFuzz iterators for valid Tor directory requests

2. Mutate valid requests with radamsa / BFF / ?

3. Define "failure" of tor to process a request "correctly" (crashes? memory access? more?)

4. Configure dmalloc on fuzzing target builds (to crash? on "failure")

5. Automate request logging and failure identification

6. Work out how to confirm and report failures responsibly

[0] https://github.com/twilsonb/tor-research-framework/blob/master/src/test/DESIGN

[1] https://github.com/twilsonb/tor-research-framework/blob/master/src/test/DIRECTORY_URL_SPEC

[2] https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt

[3] https://github.com/twilsonb/tor-research-framework/tree/master/src/test

[4] https://www.owasp.org/index.php/JBroFuzz

[5] https://code.google.com/p/ouspg/wiki/Radamsa

[6] http://caca.zoy.org/wiki/zzuf

[7] http://www.cert.org/vulnerability-analysis/tools/bff.cfm

[8] https://github.com/twilsonb/tor-research-framework/tree/master/src/test/examples

On 12 Aug 2014, at 4:47, Gareth Owen <gareth.owen@xxxxxxxxxx> wrote:

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@xxxxxxxxxx> wrote:

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.
>

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

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

--
Dr Gareth Owen
Senior Lecturer
School of Computing, University of Portsmouth

Tel: 02392 846423
Web: ghowen.me