[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On 13 Aug 2014, at 22:33 , George Kadianakis <desnacked@xxxxxxxxxx> wrote:

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.

Gareth has implemented Tor's crypto in tor-research-framework[0] in Java.

Would this be sufficient for Peach, or does it need to be written in Python?




On 13 Aug 2014, at 22:33 , George Kadianakis <desnacked@xxxxxxxxxx> wrote:

Tim <t_ebay@xxxxxxxxxx> writes:

On 13 Aug 2014, at 0:10, George Kadianakis <desnacked@xxxxxxxxxx> wrote:

Gareth Owen <gareth.owen@xxxxxxxxxx> 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:

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