
Fuzzing Irssi - jbisch
https://irssi.org/2017/05/12/fuzzing-irssi/
======
gshrikant
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
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.

------
yjftsjthsd-h
This 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?

~~~
zingermc
Even simpler, shouldn't the configuration be part of the fuzzed input?

~~~
jbisch
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](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.

------
Kali909
This fuzzing is interesting stuff. Does anyone know of an in-process or
otherwise lib for the JVM? Findbugs is mentioned in here but I'm not sure if
that does fuzzing (maybe a plugin?).

Seems in my mind to be a nice complement to achieving code-coverage with
testing i.e. whereas unit/integration testing might test the various code
paths with a few good/bad values, this then throws every possible input value
at them to see what breaks.

~~~
weinzierl
Not exactly a fuzzer in the sense of afl but there is EvoSuite[1]. It
automatically generates JUnit tests that try to satisfy a coverage criterion.

[1] [http://www.evosuite.org/](http://www.evosuite.org/)

~~~
Kali909
Thanks for the suggestions, will have a closer look at this and PIT.

