Tim t_ebay@icloud.com writes:
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?
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/54105204e91ed2d26e747e10fb217...: