AWS CSA certified. Most of my industry experience has been with backend/fullstack Python. Some amateur computer security experience, specifically with fuzzing, primarily with IRC clients. You can see my name credited on the Irssi security page, as an example of one particular client: https://irssi.org/security/.
Have published a couple of blog posts on the Irssi blog concerning fuzzing Irssi:
This is a big deal imo. There are many tutorials out there on fuzzing servers, but anything that abstracts away the source code changes necessary to fuzz servers is a great thing. Essentially this is taking what those tutorials do and making it so you don't have to adapt those tutorials to the particular software you are dealing with. If it is easier to fuzz software, more fuzzing will be done leading to more bugs being discovered and fixed.
At The Irssi Project, fuzzing has been very effective in helping to discover bugs. Fuzzing can turn up bugs that aren't otherwise found or that are unreproducible through typical use of the program. See https://irssi.org/security/.
Of course Irssi is a client, not a server. IRC servers often have protections against frequent connections and messages, which can result in fuzzers getting kicked. So this new development in TCP server fuzzing outlined in the article is a great improvement, but there are going to be cases where the code of the server will have to be modified moreso than just swapping out the main function (which I know the author never claims to not be the case).
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.
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.
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.
Remote: Yes
Willing to relocate: Yes
Technologies: Python, SQL, AWS, Flask, HTML, CSS, JavaScript, Linux
Résumé/CV: https://www.linkedin.com/in/josephbisch/ (Email for PDF résumé)
email: joseph.bisch[at]gmail.com
AWS CSA certified. Most of my industry experience has been with backend/fullstack Python. Some amateur computer security experience, specifically with fuzzing, primarily with IRC clients. You can see my name credited on the Irssi security page, as an example of one particular client: https://irssi.org/security/.
Have published a couple of blog posts on the Irssi blog concerning fuzzing Irssi:
* https://irssi.org/2017/05/12/fuzzing-irssi/
* https://irssi.org/2018/01/24/pyircfuzz/