[tor-dev] [tor-talk] Tor Research Framework update
desnacked at riseup.net
Wed Aug 13 12:33:56 UTC 2014
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 , 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
- 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.
More information about the tor-dev