Hello,
I was browsing the tor site in order to find an idea for my masters project in security and I came across the following:
----------------------------------------------------------------------
In your project ideas page https://www.torproject.org/getinvolved/volunteer.html.en#torCleanup
You have the following :
Write a fuzzer for Tor to discover security vulnerabilities. Determine if there are good fuzzing frameworks out there for what we want. Win fame by getting credit when we put out a new release because of you!
------------------------------------------------------------------------------------
I have no experience in fuzzers but I think it would be a very nice topic to learn and on the same time contribute.
I see that it is possible to create a private tor network for testing
https://www.torproject.org/docs/faq#PrivateTorNetwork
And maybe use the command line options to have as one point of input
https://www.torproject.org/docs/tor-manual.html.en
Bassically I send this email for 2 reasons:
1) To see if there are ways that you guys can help me with this on the future
and
2) To give me any starting tips mostly related to what type of data that would be good for testing, any other input places from where data can be fed and generally any kind of usefull info related to this.
Thanks a lot and have a nice day
Pietro.
On Tue, Jan 7, 2014 at 11:33 AM, Pietro Bempos pietrov@gmail.com wrote:
Hello,
I was browsing the tor site in order to find an idea for my masters project in security and I came across the following:
[...]
Bassically I send this email for 2 reasons:
- To see if there are ways that you guys can help me with this on the
future
and
- To give me any starting tips mostly related to what type of data that
would be good for testing, any other input places from where data can be fed and generally any kind of usefull info related to this.
Thanks a lot and have a nice day
Pietro.
Hi, Pietro!
Another place to read, if you haven't already, would be the Tor design paper and the protocol specifications. (Both are linked from our documentation page, I believe.) These explain how the protocol is supposed to work.
Broadly speaking, Tor sends end-to-end commands in "relay cells" that are sent over circuits. Relay cells and circuit-construction cells (and some others) are sent over a cell protocol. This cell protocol is encrypted with SSL.
IMO it makes sense to fuzz each layer separately. For layers that involve an authentication step or a setup step, I think it makes sense to do a pre-authentication/setup fuzz (to try to find flaws in the introduction steps) and a post-authentication/setup fuzz (to try to find flaws in parsing and logic that happens after authentication).
So I'd suggest a few points for injecting fuzzing data into a Tor node or client.
1) Into the SSL layer 2) Into the SSL layer, after the handshake. 3) Into the cell layer at each stage of the handshake 4) Into the cell layer, after the handshake 5) Into relay cells on a constructed circuit 6) Into INTRODUCE1 or INTRODUCE2 cells targeted at an introduction point. 7) Into directory objects to be parsed. 8) Into the HTTP layer of the directory subsystem.
Some of those (like 7) will be best accomplished by calling into the code directly.
Reading the specs and the design paper would probably help identify more places to look.
If you like Java, you might also want to have a look at modifying the Orchid source code to build your fuzzer. Remember to point your fuzzer at a private network. :)
Naturally, if you _do_ find something nasty, it would be cool if you can drop us a line (encrypted would be nice) before publishing so that we have time to fix it.
best wishes,
-
Nick Mathewson -
Pietro Bempos