Hi all
I thought I'd give you an update on where the Tor Research Framework is now at as there's been lots of development over the last few weeks. At present, the framework is a largely fully functional tor client with code that is easy to read, follow and crucially change for custom functionality.
URL: https://github.com/drgowen/tor-research-framework
Completed =======
The examples exercise a big chunk of the functionality so in the examples directory, we now have examples on how to do:
- Circuit building, Random circuits based on flags, etc - Building HS circuits and establishing streams to their service - Consensus parsing examples - RELAY_EARLY scanner - scans HSDirs looking for RELAY_EARLYs coming the wrong way (aka the recent Blackhat deanon attack) - Tor SOCKS Proxy and PortForwarder
The examples are here: https://github.com/drgowen/tor-research-framework/tree/master/src/main/java/...
The RELAY_EARLY scanner took around five minutes to write for example and didn't require modifying core library code.
Work in progress ==========
Fuzzer: We also have another chap (twilsonb) working on a fuzzing framework for Tor that is capable of fuzzing the protocol and directory services - although this is at early stage I'm sure he'd welcome help from anyone interested.
Relay: We're working on building the capability to act as a Tor relay with examples for building malicious guard nodes that deny circuits or do correlation attacks.
Naturally, we'll also look later down the line at optionally integrating with the shadow simulator for research which shouldn't be done on the live network.
-- If anyone is interested in helping out then please dont hesitate to get in touch.
Best Gareth
Gareth Owen gareth.owen@port.ac.uk writes:
Hi all
I thought I'd give you an update on where the Tor Research Framework is now at as there's been lots of development over the last few weeks. At present, the framework is a largely fully functional tor client with code that is easy to read, follow and crucially change for custom functionality.
URL: https://github.com/drgowen/tor-research-framework
Completed
The examples exercise a big chunk of the functionality so in the examples directory, we now have examples on how to do:
- Circuit building, Random circuits based on flags, etc
- Building HS circuits and establishing streams to their service
- Consensus parsing examples
- RELAY_EARLY scanner - scans HSDirs looking for RELAY_EARLYs coming the
wrong way (aka the recent Blackhat deanon attack)
- Tor SOCKS Proxy and PortForwarder
The examples are here: https://github.com/drgowen/tor-research-framework/tree/master/src/main/java/...
The RELAY_EARLY scanner took around five minutes to write for example and didn't require modifying core library code.
Work in progress
Fuzzer: We also have another chap (twilsonb) working on a fuzzing framework for Tor that is capable of fuzzing the protocol and directory services - although this is at early stage I'm sure he'd welcome help from anyone interested.
Great! Tor needs better fuzzing :)
I have conducted two activities in this area:
- I once started the ambitious project of making a Tor protocol fuzzer [0]. I used the Peach fuzzing framework, a decision I later regreted. In the end, the fuzzer could successfully fuzz the first few cells of the v3 handshake, but I never implemented Tor's crypto which was necessary for fuzzing deeper.
I think there is still lots of value in a fuzzer that can walk the various areas of the Tor protocol (circuit building, HSes, etc.) If I were to do this now, I would probably write my own networking code and only use a premade framework to procuce fuzzed output.
- I used the radamsa mutator [1] and fed Tor tons of mutated descriptors, consensuses and hidden service descriptors. This was quite fun and effective: within a few hours it found #6811 which was a nice crash bug. FWIW, I don't think I ever fuzzed all the various directory documents of Tor this way...
I think this is a fast and easy way of fuzzing the directory part of Tor, which has wide parsing attack surface.
Feel free to discuss any aspects of Tor fuzzer development in this mailing list! (but please send any found 0days to Tor developers in a confidential manner ;) )
[0]: https://gitorious.org/tor_fuzz/tor_fuzz/source/54105204e91ed2d26e747e10fb217...: [1]: https://code.google.com/p/ouspg/wiki/Radamsa
Hi George
Thanks for your reply and information+links. Tim (cc-ed) is leading the work on the fuzzer and is looking at a couple of different frameworks. I've set up a example that can do port-forwarding to a BEGIN_DIR service - so you can just point a fuzzer at the local port - this opens up a wider range of potential targets (some paths on the directory service are over Tor only) .
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.
Looking through the source, I agree that there's a very large surface area and also there's a lot of manual string manipulation which is potentially error prone. It's reassuring that you've already found bugs this way, it suggests the route isn't a complete dead-end.
I've cc-ed Tim, so he might pick your brains !
Thanks Gareth
On 11 August 2014 18:19, George Kadianakis desnacked@riseup.net wrote:
Gareth Owen gareth.owen@port.ac.uk writes:
Hi all
I thought I'd give you an update on where the Tor Research Framework is
now
at as there's been lots of development over the last few weeks. At
present,
the framework is a largely fully functional tor client with code that is easy to read, follow and crucially change for custom functionality.
URL: https://github.com/drgowen/tor-research-framework
Completed
The examples exercise a big chunk of the functionality so in the examples directory, we now have examples on how to do:
- Circuit building, Random circuits based on flags, etc
- Building HS circuits and establishing streams to their service
- Consensus parsing examples
- RELAY_EARLY scanner - scans HSDirs looking for RELAY_EARLYs coming the
wrong way (aka the recent Blackhat deanon attack)
- Tor SOCKS Proxy and PortForwarder
The examples are here:
https://github.com/drgowen/tor-research-framework/tree/master/src/main/java/...
The RELAY_EARLY scanner took around five minutes to write for example and didn't require modifying core library code.
Work in progress
Fuzzer: We also have another chap (twilsonb) working on a fuzzing
framework
for Tor that is capable of fuzzing the protocol and directory services - although this is at early stage I'm sure he'd welcome help from anyone interested.
Great! Tor needs better fuzzing :)
I have conducted two activities in this area:
I once started the ambitious project of making a Tor protocol fuzzer [0]. I used the Peach fuzzing framework, a decision I later regreted. In the end, the fuzzer could successfully fuzz the first few cells of the v3 handshake, but I never implemented Tor's crypto which was necessary for fuzzing deeper.
I think there is still lots of value in a fuzzer that can walk the various areas of the Tor protocol (circuit building, HSes, etc.) If I were to do this now, I would probably write my own networking code and only use a premade framework to procuce fuzzed output.
I used the radamsa mutator [1] and fed Tor tons of mutated descriptors, consensuses and hidden service descriptors. This was quite fun and effective: within a few hours it found #6811 which was a nice crash bug. FWIW, I don't think I ever fuzzed all the various directory documents of Tor this way...
I think this is a fast and easy way of fuzzing the directory part of Tor, which has wide parsing attack surface.
Feel free to discuss any aspects of Tor fuzzer development in this mailing list! (but please send any found 0days to Tor developers in a confidential manner ;) )
: [1]: https://code.google.com/p/ouspg/wiki/Radamsa
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi George,
I'm still trying to work out exactly how to go about fuzzing Tor. So far, I've been to defined an initial problem space, configured a test environment, and explored some fuzzing libraries / tools.
Fuzzing Problem Space
We started by looking at fuzzing Tor directory download requests over HTTP. This seemed like a manageable initial chunk of work.
I sketched an early draft design[0], and developed an annotated grammar for Tor directory requests[1] based on the Tor directory spec[2].
Configuring a Test Environment
I created scripts and configuration files to build, run and monitor a local-only tor directory cache.[3] I configured hardened, typical, and feature-full builds, all with dmalloc to catch memory access errors. I plan to start testing on the feature-full build, then re-test failures against the builds with smaller surfaces.
Exploring Fuzzing Tools / Libraries
JBroFuzz[4] is a HTTP / browser fuzzer written in Java. (tor-research-framework is also written in Java.) It focuses on exhaustive iteration through a set of alternatives.
I anticipate using JBroFuzz as a library to generate correct and near-correct requests to a tor instance. It may also be useful interactively, although the included analysis / graphing tools didn't work in my build. (And it's listed as "inactive".)
Thanks for the pointer to radamsa[5], it looks like it's much more structure-aware than many of the other black-box fuzzes I've looked at. I could imagine using radamsa to mutate correct requests on their way to tor. (JBroFuzz isn't designed to do random mutation.)
I've also looked at at zzuf[6], which appears unloved, but is incorporated into the CERT Basic Fuzzing Framework[7]. The set of zuff/BFF mutations is limited to bit-level flips, and isn't syntax-aware. Hooking into all the target process' file descriptors is neat, but it requires a local(-only) process to fuzz.
Results
Certain parts of directory request URLs get written to the tor debug log unescaped.[8] But the effect is severely limited: it simply makes reading the log in a terminal irritating (including BEL, DEL, and CR effects - the BEL effect was how I discovered the issue).
Further Work
These are the tasks I can think of:
1. Write JBroFuzz iterators for valid Tor directory requests 2. Mutate valid requests with radamsa / BFF / ? 3. Define "failure" of tor to process a request "correctly" (crashes? memory access? more?) 4. Configure dmalloc on fuzzing target builds (to crash? on "failure") 5. Automate request logging and failure identification 6. Work out how to confirm and report failures responsibly
[0] https://github.com/twilsonb/tor-research-framework/blob/master/src/test/DESI... [1] https://github.com/twilsonb/tor-research-framework/blob/master/src/test/DIRE... [2] https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt [3] https://github.com/twilsonb/tor-research-framework/tree/master/src/test [4] https://www.owasp.org/index.php/JBroFuzz [5] https://code.google.com/p/ouspg/wiki/Radamsa [6] http://caca.zoy.org/wiki/zzuf [7] http://www.cert.org/vulnerability-analysis/tools/bff.cfm [8] https://github.com/twilsonb/tor-research-framework/tree/master/src/test/exam...
On 12 Aug 2014, at 4:47, Gareth Owen gareth.owen@port.ac.uk wrote:
Hi George
Thanks for your reply and information+links. Tim (cc-ed) is leading the work on the fuzzer and is looking at a couple of different frameworks. I've set up a example that can do port-forwarding to a BEGIN_DIR service - so you can just point a fuzzer at the local port - this opens up a wider range of potential targets (some paths on the directory service are over Tor only) .
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.
Looking through the source, I agree that there's a very large surface area and also there's a lot of manual string manipulation which is potentially error prone. It's reassuring that you've already found bugs this way, it suggests the route isn't a complete dead-end.
I've cc-ed Tim, so he might pick your brains !
Thanks Gareth
On 11 August 2014 18:19, George Kadianakis desnacked@riseup.net wrote: Gareth Owen gareth.owen@port.ac.uk writes:
Hi all
I thought I'd give you an update on where the Tor Research Framework is now at as there's been lots of development over the last few weeks. At present, the framework is a largely fully functional tor client with code that is easy to read, follow and crucially change for custom functionality.
URL: https://github.com/drgowen/tor-research-framework
Completed
The examples exercise a big chunk of the functionality so in the examples directory, we now have examples on how to do:
- Circuit building, Random circuits based on flags, etc
- Building HS circuits and establishing streams to their service
- Consensus parsing examples
- RELAY_EARLY scanner - scans HSDirs looking for RELAY_EARLYs coming the
wrong way (aka the recent Blackhat deanon attack)
- Tor SOCKS Proxy and PortForwarder
The examples are here: https://github.com/drgowen/tor-research-framework/tree/master/src/main/java/...
The RELAY_EARLY scanner took around five minutes to write for example and didn't require modifying core library code.
Work in progress
Fuzzer: We also have another chap (twilsonb) working on a fuzzing framework for Tor that is capable of fuzzing the protocol and directory services - although this is at early stage I'm sure he'd welcome help from anyone interested.
Great! Tor needs better fuzzing :)
I have conducted two activities in this area:
I once started the ambitious project of making a Tor protocol fuzzer [0]. I used the Peach fuzzing framework, a decision I later regreted. In the end, the fuzzer could successfully fuzz the first few cells of the v3 handshake, but I never implemented Tor's crypto which was necessary for fuzzing deeper.
I think there is still lots of value in a fuzzer that can walk the various areas of the Tor protocol (circuit building, HSes, etc.) If I were to do this now, I would probably write my own networking code and only use a premade framework to procuce fuzzed output.
I used the radamsa mutator [1] and fed Tor tons of mutated descriptors, consensuses and hidden service descriptors. This was quite fun and effective: within a few hours it found #6811 which was a nice crash bug. FWIW, I don't think I ever fuzzed all the various directory documents of Tor this way...
I think this is a fast and easy way of fuzzing the directory part of Tor, which has wide parsing attack surface.
Feel free to discuss any aspects of Tor fuzzer development in this mailing list! (but please send any found 0days to Tor developers in a confidential manner ;) )
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- Dr Gareth Owen Senior Lecturer School of Computing, University of Portsmouth
Tel: 02392 846423 Web: ghowen.me
Gareth Owen gareth.owen@port.ac.uk writes:
Hi George
Thanks for your reply and information+links. Tim (cc-ed) is leading the work on the fuzzer and is looking at a couple of different frameworks. I've set up a example that can do port-forwarding to a BEGIN_DIR service
- so you can just point a fuzzer at the local port - this opens up a wider
range of potential targets (some paths on the directory service are over Tor only) .
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.
My specific targets where the cell processing functions and the guards they have on top. These guards enforce the state machine (they kick you out if you send unexpected cells) and make sure that various necessary actions have occured (for example they check that certain attributes of the channel structs have been initialized).
For example, see rend_mid_establish_intro() and how it guards in the beginning: """ if (circ->base_.purpose != CIRCUIT_PURPOSE_OR || circ->base_.n_chan) { log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL, "Rejecting ESTABLISH_INTRO on non-OR or non-edge circuit."); reason = END_CIRC_REASON_TORPROTOCOL; goto err; } """
You can see similar checks in the other cell parsing functions. 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.
On 13 Aug 2014, at 0:10, George Kadianakis desnacked@riseup.net wrote:
Gareth Owen gareth.owen@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?
Or would you recommend different fuzzing strategies entirely? (Given that different fuzzers explore different parts of the codebase in different ways.)
Tim
Tim t_ebay@icloud.com writes:
On 13 Aug 2014, at 0:10, George Kadianakis desnacked@riseup.net wrote:
Gareth Owen gareth.owen@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/54105204e91ed2d26e747e10fb217...:
On 13 Aug 2014, at 22:33 , George Kadianakis desnacked@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@riseup.net wrote:
Tim t_ebay@icloud.com writes:
On 13 Aug 2014, at 0:10, George Kadianakis desnacked@riseup.net wrote:
Gareth Owen gareth.owen@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!
Tim t_ebay@icloud.com writes:
On 13 Aug 2014, at 22:33 , George Kadianakis desnacked@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?
I don't know. I think it needs to be written in Python, or you need to write bindings or something... But better check this yourself, I haven't looked into Peach in years.
Tim t_ebay@icloud.com writes:
On 13 Aug 2014, at 22:33 , George Kadianakis desnacked@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?
Did anything interesting happen after all? :)
On 13 Sep 2014, at 06:19 , George Kadianakis desnacked@riseup.net wrote:
Tim t_ebay@icloud.com writes:
On 13 Aug 2014, at 22:33 , George Kadianakis desnacked@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?
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
-
Gareth Owen -
George Kadianakis -
Tim