4 ms·

I'm new to fuzzers and fuzz testing in general so I apologise for my ignorance about the purpose of fuzzing. My understanding is that fuzzing tests the user fac

I'm new to fuzzers and fuzz testing in general so I apologise for my ignorance about the purpose of fuzzing. My understanding is that fuzzing tests the user facing side (which is what is important for most programs). Does there exist similar tooling for testing the system-facing side (i.e. the stack below your application) to check your applications error handling, for example and uncover corner cases. What I'm getting at it something like syzkaller but for userspace, so library functions beneath your application would return wrong values and you get to see how your application responds to them. Sorry for the bad English.

jbisch 9y ago
It sounds like you already have a good understanding of fuzzing. You might want to take a look at libfuzzer (http://llvm.org/docs/LibFuzzer.html http://llvm.org/docs/LibFuzzer.html), which you can use to test library functions. What you do is implement a function called LLVMFuzzerTestOneInput that should call whatever library function you want to test. One of the parameters is a uint8_t array that can be transformed into whatever kind of parameter types the library function expects. Then libfuzzer provides the main function that will generate the data and call the LLVMFuzzerTestOneInput function, repeating the process until there is a crash. The one downside is that you need to recompile the code (the library) you are trying to fuzz.
cmrx64 9y ago
This is usually called "fault injection". Check out https://blitiri.com.ar/p/libfiu/ https://blitiri.com.ar/p/libfiu/
cel1ne 9y ago
I've started writing a fuzzer for the JVM once. It looks at the bytecode and adds instrumentation to check whether a label has been hit = a code-path has been traversed after calling methods. It uses genetic algorithms to spawn agents that call an API with all kinds of arguments and reproduce when it finds unique code-paths. Before anyone asks: the code is far from complete, it's really more a fiddle than anything.
sporkenfang 9y ago
Yes! Static and dynamic code analysis (for JVM a popular analysis tool is Findbugs, which is incidentally built into InrelliJ; another one that's okay that I've used before is Coverity Code Advisor) are what you're looking for I think, instead of API endpoint analysis, which is what fuzzing usually boils down to (e.g. What can I pass to this program to make it barf).
mkj 9y ago
I've been thinking about this for fuzzing my own ssh server, there are various paths that depend on external stimuli other than the main network stream - TCP data incoming or writable, TCP sockets closed, processes exiting etc. It seems that wrapping select()/read()/write() to have random readability/writability/closing seeded by a fuzz input might exercise those code paths. I'm yet to implement it though - be interested to hear of prior work. Getting the fuzz input corpus to correlate to program actions might be problematic.

jbisch 9y ago

It sounds like you already have a good understanding of fuzzing. You might want to take a look at libfuzzer (http://llvm.org/docs/LibFuzzer.html http://llvm.org/docs/LibFuzzer.html), which you can use to test library functions. What you do is implement a function called LLVMFuzzerTestOneInput that should call whatever library function you want to test. One of the parameters is a uint8_t array that can be transformed into whatever kind of parameter types the library function expects. Then libfuzzer provides the main function that will generate the data and call the LLVMFuzzerTestOneInput function, repeating the process until there is a crash. The one downside is that you need to recompile the code (the library) you are trying to fuzz.

cmrx64 9y ago

This is usually called "fault injection". Check out https://blitiri.com.ar/p/libfiu/ https://blitiri.com.ar/p/libfiu/

cel1ne 9y ago

I've started writing a fuzzer for the JVM once. It looks at the bytecode and adds instrumentation to check whether a label has been hit = a code-path has been traversed after calling methods. It uses genetic algorithms to spawn agents that call an API with all kinds of arguments and reproduce when it finds unique code-paths. Before anyone asks: the code is far from complete, it's really more a fiddle than anything.

sporkenfang 9y ago

Yes! Static and dynamic code analysis (for JVM a popular analysis tool is Findbugs, which is incidentally built into InrelliJ; another one that's okay that I've used before is Coverity Code Advisor) are what you're looking for I think, instead of API endpoint analysis, which is what fuzzing usually boils down to (e.g. What can I pass to this program to make it barf).

mkj 9y ago

I've been thinking about this for fuzzing my own ssh server, there are various paths that depend on external stimuli other than the main network stream - TCP data incoming or writable, TCP sockets closed, processes exiting etc. It seems that wrapping select()/read()/write() to have random readability/writability/closing seeded by a fuzz input might exercise those code paths. I'm yet to implement it though - be interested to hear of prior work. Getting the fuzz input corpus to correlate to program actions might be problematic.