I recently completed my Master Thesis, a joint thesis between ETH Zürich and Gapfruit AG. The practical part of the thesis focused on porting AFL++ to Genode in order to provide the functionality to fuzz Genode specific interfaces or sessions!
shm-server provides a (uncomplete) POSIX interface for shared memory, which AFL++ makes heavy use of, through a custom session type.
genode-afl-fuzz contains AFL++’ functionality which runs the fuzzing campaign.
Currently, the code is available on my Github Fork and uses the August version (24.08) of Genode. Some more work will be required to improve the UX, for example making the functionality usable without changing the port’s source code. Additionally, as I have noted in the future work section of the thesis, I would like to add some additional performance enhancements in order to properly fuzz a session.
I’m looking forward to your feedback and potential questions!
While others are still digesting the thesis PDF, I’d like to mention I found it very very readable (it’s nice that it does not assume the reader is already familiar with fuzzers etc but walks them through the concepts). I might be naive but I’m kinda hoping this work could be included in the official Genode test-suites in the future in some capacity, doing weekly(?) runs, aiming at finding vulnerabilities for them to be fixed and make the Genode framework even more robust.
It sounds like having fuzzing capabilies would create additional “legitimacy” for Genode and help make it more popular (and who knows, maybe even smhm will keep an eye on it )
Thanks @smhm for sharing this impressive work! I thoroughly enjoyed reading the thesis, following your line of reasoning, and learning about the fuzzing landscape along the way. I also very much appreciated the tasteful presentation and writing style.
In the outlook, you already sketched a few interesting directions. I like in particular the idea of merging the report-rom, SUT-init, and genode-afl-fuzz into one component. This looks like a perfect use case for the sandbox library. Similar to how the os/src/monitor component is a special version of init that adds the GDB protocol, the fuzzer could also be a special variant init in a simiar way. With this approach, one could implement more accurate (and performant) fault detection similar to how the monitor can detect segfaults.
Another idea that came into my mind - when you talked about the tooling peculiarities of linking a subset of components differently depending on their role as execution environment or SUT - was applying the Goa-testbed approach, which in principle “beams” the SUT over the network to a remote testing machine for execution under Sculpt OS. This would cleanly separate the execution environment from the SUV and would allows for distributing the fuzzing on many machines in parallel.
Well, in short, I found your thesis delightful and thought provoking.
)