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

[Tim]

On 13 Aug 2014, at 22:33 , George Kadianakis <desnacked at riseup.net> 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?

[0] https://github.com/drgowen/tor-research-framework



On 13 Aug 2014, at 22:33 , George Kadianakis <desnacked at riseup.net> wrote:

> 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:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140814/20d387ca/attachment.html>