Fuzzing Irssi
irssi.org
Fuzzing Irssi
1–10 of 16 posts
Re: Fuzzing Irssi
#2This notes that they disabled reading config files in order to own life as the default setup. I assume that with more time it would be wise to try and fuzz as many configured options as possible as well?
Re: Fuzzing Irssi
#3This notes that they disabled reading config files in order to own life as the default setup. I assume that with more time it would be wise to try and fuzz as many configured options as possible as well?
Yes, that is what I was trying to get at in the second paragraph under the "What can I do to help with fuzzing Irssi?…" heading. That there may be certain bugs that require certain non-default configuration options as part of the criteria for triggering the bug.
Re: Fuzzing Irssi
#4This notes that they disabled reading config files in order to own life as the default setup. I assume that with more time it would be wise to try and fuzz as many configured options as possible as well?
Even simpler, shouldn't the configuration be part of the fuzzed input?
Re: Fuzzing Irssi
#5This notes that they disabled reading config files in order to own life as the default setup. I assume that with more time it would be wise to try and fuzz as many configured options as possible as well?
Even simpler, shouldn't the configuration be part of the fuzzed input?
I actually did do some fuzzing of the config file (just loading Irssi to see if the config file caused a crash) and found a couple of bugs there (for example: https://github.com/irssi/irssi/issues/563). The choice to instead fuzz network traffic as done in the blog post was made, because it is generally more interesting because it is easier for a malicious person to exploit network based bugs than those requiring the user to load a bad config.
But you are right, that the configuration can be part of the fuzzed input. It should be possible to take part of the data fed into Irssi by AFL and use that as the config file and then use the rest as the network traffic.
Re: Fuzzing Irssi
#6I'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.
Re: Fuzzing Irssi
#7I'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 getti…
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), 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.
Re: Fuzzing Irssi
#8I'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 getti…
This is usually called "fault injection". Check out https://blitiri.com.ar/p/libfiu/
Re: Fuzzing Irssi
#9I'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 getti…
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.
Re: Fuzzing Irssi
#10I'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 getti…
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).