<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On 13 Aug 2014, at 22:33 , George Kadianakis <<a href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>> wrote:<div><br><blockquote type="cite">My plan was to make a Peach fuzzer to achieve this [0], but as I<br>mentioned in a previous email I never got past the V3 link handshake<br>since I actually had to implement Tor's crypto to get past.<br><br>Someone would need to implement all this stuff to be able to fuzz the<br>Tor protocol as I was intending to.</blockquote><div><br></div><div>Gareth has implemented Tor's crypto in tor-research-framework[0] in Java.</div><div><br></div><div>Would this be sufficient for Peach, or does it need to be written in Python?</div><div><br></div><div>[0] <i style="white-space: pre-wrap;"><a href="https://github.com/drgowen/tor-research-framework">https://github.com/drgowen/tor-research-framework</a></i></div><div><br></div><br><br><div><div>On 13 Aug 2014, at 22:33 , George Kadianakis <<a href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Tim <<a href="mailto:t_ebay@icloud.com">t_ebay@icloud.com</a>> writes:<br><br><blockquote type="cite"><blockquote type="cite">On 13 Aug 2014, at 0:10, George Kadianakis <<a href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>> wrote:<br><br>Gareth Owen <<a href="mailto:gareth.owen@port.ac.uk">gareth.owen@port.ac.uk</a>> writes:<br></blockquote>...<br><blockquote type="cite"><blockquote type="cite">The framework implements the tor protocol so should be easy to modify to do<br>fuzzing of the actual protocol but I'm skeptical how successful this would<br>be, I can only think of a couple of places that could be error prone.<br></blockquote><br>Interesting point!<br><br>I admit that my main intention with that fuzzer was to implement the<br>state machine of the Tor protocol, and then make it so that the fuzzer<br>would do a random walk over all the possible states.<br><br>My intention was to check the robustness of Tor's state machine by<br>testing whether it would get confused if I send it unexpected cells in<br>unexpected times.<br></blockquote>...<br><blockquote type="cite">Because of the fail-open nature of those guards, I have a<br>hunch that some of those checks might not be robust and some necessary<br>ones might not exist at all.<br><br>That said, I have spent many hours auditing Tor for these bugs and I<br>still haven't found anything particularly interesting so maybe it's<br>not a good idea. My best catch (IIRC) was #5644, a fun crash bug.<br></blockquote><br>George, do you think you've exhausted the fuzzing space in this area?<br>Is this the sort of project that requires more processor time (i.e. volunteers to run test instances until they crash?)<br>Or more analysis once they crash?<br><br></blockquote><br>I have not exhausted the fuzzing space in this area at all.<br><br>My plan was to make a Peach fuzzer to achieve this [0], but as I<br>mentioned in a previous email I never got past the V3 link handshake<br>since I actually had to implement Tor's crypto to get past.<br><br>Someone would need to implement all this stuff to be able to fuzz the<br>Tor protocol as I was intending to.<br><br><blockquote type="cite">Or would you recommend different fuzzing strategies entirely?<br>(Given that different fuzzers explore different parts of the codebase in different ways.)<br></blockquote><br>To be honest I don't know if my strategy would have been fruitful :)<br>It's probably not the easiest way or most effective way to fuzz for Tor bugs.<br><br>On the easy side, I think that fuzzing directory documents (while also<br>checking for memory leaks and invalid memory accesses using valgrind)<br>might produce some cheap fruits of labor, like these:<br><br> - Fix a memory leak that could occur if a microdescriptor parse<br> fails during the tokenizing step. This bug could enable a memory<br> exhaustion attack by directory servers. Fixes bug 11649; bugfix<br> on 0.2.2.6-alpha.<br><br> - Fix a denial of service attack by which any directory authority<br> could crash all the others, or by which a single v2 directory<br> authority could crash everybody downloading v2 directory<br> information. Fixes bug 7191; bugfix on 0.2.0.10-alpha.<br><br><br>Enjoy! <br><br>[0]: <a href="https://gitorious.org/tor_fuzz/tor_fuzz/source/54105204e91ed2d26e747e10fb21710aecfaf8b3:">https://gitorious.org/tor_fuzz/tor_fuzz/source/54105204e91ed2d26e747e10fb21710aecfaf8b3:</a><br></blockquote></div><br></div></body></html>