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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Gareth Owen <gareth.owen@xxxxxxxxxx> writes:

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

Interesting point!

I admit that my main intention with that fuzzer was to implement the
state machine of the Tor protocol, and then make it so that the fuzzer
would do a random walk over all the possible states.

My intention was to check the robustness of Tor's state machine by
testing whether it would get confused if I send it unexpected cells in
unexpected times.

My specific targets where the cell processing functions and the guards
they have on top. These guards enforce the state machine (they kick
you out if you send unexpected cells) and make sure that various
necessary actions have occured (for example they check that certain
attributes of the channel structs have been initialized).

For example, see rend_mid_establish_intro() and how it guards in the
beginning:
"""
  if (circ->base_.purpose != CIRCUIT_PURPOSE_OR || circ->base_.n_chan) {
    log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
         "Rejecting ESTABLISH_INTRO on non-OR or non-edge circuit.");
    reason = END_CIRC_REASON_TORPROTOCOL;
    goto err;
  }
"""

You can see similar checks in the other cell parsing
functions. Because of the fail-open nature of those guards, I have a
hunch that some of those checks might not be robust and some necessary
ones might not exist at all.

That said, I have spent many hours auditing Tor for these bugs and I
still haven't found anything particularly interesting so maybe it's
not a good idea. My best catch (IIRC) was #5644, a fun crash bug.

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