[tor-dev] fuzzer for tor as a masters project

[Nick Mathewson]

On Tue, Jan 7, 2014 at 11:33 AM, Pietro Bempos <pietrov at gmail.com> wrote:
> Hello,
>
> I was browsing the tor site in order to find an idea for my masters project
> in security and I came across the following:
>
 [...]
>
> Bassically I send this email for 2 reasons:
>
> 1) To see if there are ways that you guys can help me with this on the
> future
>
> and
>
> 2) To give me any starting tips mostly related to what type of data that
> would be good for testing, any other input places from where data can be fed
> and generally any kind of usefull info related to this.
>
> Thanks a lot and have a nice day
>
> Pietro.

Hi, Pietro!

Another place to read, if you haven't already, would be the Tor design
paper and the protocol specifications. (Both are linked from our
documentation page, I believe.)  These explain how the protocol is
supposed to work.


Broadly speaking, Tor sends end-to-end commands in "relay cells" that
are sent over circuits.  Relay cells and circuit-construction cells
(and some others) are sent over a cell protocol.  This cell protocol
is encrypted with SSL.

IMO it makes sense to fuzz each layer separately.  For layers that
involve an authentication step or a setup step, I think it makes sense
to do a pre-authentication/setup fuzz (to try to find flaws in the
introduction steps) and a post-authentication/setup fuzz (to try to
find flaws in parsing and logic that happens after authentication).

So I'd suggest a few points for injecting fuzzing data into a Tor node
or client.

  1) Into the SSL layer
  2) Into the SSL layer, after the handshake.
  3) Into the cell layer at each stage of the handshake
  4) Into the cell layer, after the handshake
  5) Into relay cells on a constructed circuit
  6) Into INTRODUCE1 or INTRODUCE2 cells targeted at an introduction point.
  7) Into directory objects to be parsed.
  8) Into the HTTP layer of the directory subsystem.

Some of those (like 7) will be best accomplished by calling into the
code directly.

Reading the specs and the design paper would probably help identify
more places to look.

If you like Java, you might also want to have a look at modifying the
Orchid source code to build your fuzzer.  Remember to point your
fuzzer at a private network. :)

Naturally, if you _do_ find something nasty, it would be cool if you
can drop us a line (encrypted would be nice) before publishing so that
we have time to fix it.

best wishes,
-- 
Nick