On 13 Aug 2014, at 0:10, George Kadianakis desnacked@riseup.net wrote:
Gareth Owen gareth.owen@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?
Or would you recommend different fuzzing strategies entirely? (Given that different fuzzers explore different parts of the codebase in different ways.)
Tim