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

[George Kadianakis]

Tim <t_ebay at icloud.com> writes:

>> On 13 Aug 2014, at 0:10, George Kadianakis <desnacked at riseup.net> wrote:
>> 
>> Gareth Owen <gareth.owen at port.ac.uk> writes:
> ...
>>> 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.
> ...
>> 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.
>
> George, do you think you've exhausted the fuzzing space in this area?
> Is this the sort of project that requires more processor time (i.e. volunteers to run test instances until they crash?)
> Or more analysis once they crash?
>

I have not exhausted the fuzzing space in this area at all.

My plan was to make a Peach fuzzer to achieve this [0], but as I
mentioned in a previous email I never got past the V3 link handshake
since I actually had to implement Tor's crypto to get past.

Someone would need to implement all this stuff to be able to fuzz the
Tor protocol as I was intending to.

> Or would you recommend different fuzzing strategies entirely?
> (Given that different fuzzers explore different parts of the codebase in different ways.)

To be honest I don't know if my strategy would have been fruitful :)
It's probably not the easiest way or most effective way to fuzz for Tor bugs.

On the easy side, I think that fuzzing directory documents (while also
checking for memory leaks and invalid memory accesses using valgrind)
might produce some cheap fruits of labor, like these:

    - Fix a memory leak that could occur if a microdescriptor parse
      fails during the tokenizing step. This bug could enable a memory
      exhaustion attack by directory servers. Fixes bug 11649; bugfix
      on 0.2.2.6-alpha.

    - Fix a denial of service attack by which any directory authority
      could crash all the others, or by which a single v2 directory
      authority could crash everybody downloading v2 directory
      information. Fixes bug 7191; bugfix on 0.2.0.10-alpha.


Enjoy! 

[0]: https://gitorious.org/tor_fuzz/tor_fuzz/source/54105204e91ed2d26e747e10fb21710aecfaf8b3: