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

Tim t_ebay at icloud.com
Fri Sep 12 22:16:57 UTC 2014


On 13 Sep 2014, at 06:19 , George Kadianakis <desnacked at riseup.net> wrote:

> Tim <t_ebay at icloud.com> writes:
> 
>> 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
>> 
> 
> Did anything interesting happen after all? :)


Yes, some initial work, but no actual fuzzer (yet!):


A draft design for a fuzzer:
-----------------------------------

0. I decided to focus on fuzzing tor directory requests. Although descriptor uploads 
    seemed like a juicier target due to the volume of string manipulation involved, 
    they're also far more complex to fuzz.

1. I plan to create a URL enumerator using tor-research-framework [-6] and jbrofuzz [-5].
    tor-research-framework will provide consensus info, and jbrofuzz will provide
    the URL/request iterator framework. The enumerator will enumerate valid URLs
    (for multiple definitions of "valid").

2. The output of this enumerator can also be run through a mutating fuzzer like radamsa [-4]

3. Successful fuzzing output can be recycled through the mutator to find more "crashes". [-3]

4. A similar approach can be used to fuzz other areas of tor, like descriptor uploads.


Ongoing work on tor-research-framework
-------------------------------------------------------

Gareth has made significant improvements to the TRF functionality.
He and I have also corresponded on the design / architecture of tor-research-framework. [-2]


tor builds configured for fuzzing directory requests [-1]
-----------------------------------------------------------------------

These builds are configured to detect bugs and trap on errors, making debugging easy. [1][2]
They run locally, and only act as directory caches at this time.


Patches against tor
--------------------------

A few patches have also gone into tor during the configuration and testing of the 
fuzzing targets:

Logged due to initial fuzzing attempts:

#13071 [patch] tor 0.2.6 sometimes fails to escape logged directory requests [0]

Logged due to the compiler flags I wanted to use during fuzzing [1] 
(it's far easier to fuzz a version of tor that is undefined-behaviour clean)[2]:

#13085 [patch] tor control connection event mask (32 bits) is too small for events (33 events) [3]
#13096 [patch] routerlist: NULL struct pointer dereferenced to take address of element [4]
#13104 [patch] Arithmetic undef behaviour: sscanf, memeq, scale array, fmt exit status [5]

Logged due to compiler warnings / static analysis:

#13036 Uninitialised Variable & NULL Pointer Dereference Warnings in Clang [6]

[-6]: https://github.com/drgowen/tor-research-framework
[-5]: https://github.com/twilsonb/jbrofuzz
[-4]: https://www.ee.oulu.fi/research/ouspg/Radamsa
[-3]: Like http://www.cert.org/blogs/certcc/post.cfm?EntryID=179

[-2]: I could clean this up and upload it to github (it's in emails at the moment).
[-1]: https://github.com/twilsonb/tor-research-framework/tree/master/src/test

[0]: https://trac.torproject.org/projects/tor/ticket/13071
[1]: Using clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error -ftrapv 
      makes it easier to detect subtle bugs (along with a debugging malloc library)
[2]: Once the patches in [5] are applied, (many) commonly executed tor code paths
      will be undefined-behaviour clean at runtime.
[3]: https://trac.torproject.org/projects/tor/ticket/13085
[4]: https://trac.torproject.org/projects/tor/ticket/13096
[5]: https://trac.torproject.org/projects/tor/ticket/13104
[6] : https://trac.torproject.org/projects/tor/ticket/13036

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


More information about the tor-dev mailing list