The Fuzzing Project

I'm happy to announce today that the Linux Foundation's Core Infrastructure Initiative has decided to financially support the work I'm doing for the Fuzzing Project. The Core Infrastructure Initiative (CII) was established last year after the Heartbleed bug in OpenSSL. A number of companies came together to support people improving the security of free and open source software.

For the Fuzzing Project this of course means that I will report many more bugs in the future. While in the beginning all the fuzzing work was done on my personal laptop I recently moved that to dedicated servers that fuzz applications all the time. Appart from that I'm investigating methods to further increase the ways to find bugs in large quantities. I have some preliminary experiments to use american fuzzy lop on network input. I also want to encourage developers of free software projects to get in touch with me if they think their project could profit from fuzz testing.

I also want to spend a few words on the other two projects that got supported by the CII.

One problem of free software is that you can in theory verify what the code is doing and check it for backdoors, but usually you don't compile the code yourself. You still get it in binary form from somewhere (unless you use a source-based system like Gentoo, but that's a small minority). In order to bridge this trust gap between source code and binaries the idea of reproducible builds emerged. If different people can compile the same code and will always get the same output then it can be independently verified that the code matches the binary. This is easier said than done, because you have to consider all kinds of non-deterministic behaviour, e. g. added timestamps, different compiler versions and more.

The Debian Linux distribution is currently working on reproducible builds. Debian-developers Holger Levsen and Jérémy Bobbio (Lunar) will be supported by the CII and I am very optimistic that they will make it happen and the next Debian version will be reproducible. I am glad about this because I think if we really want trustworthy software in the future we need reproducible builds. I hope that in the future we can make it a norm that trustworthy, secure software contains a reproducible build process (which by definition means open code).

Pascal Cuoq is working on improving automated, formal methods to find bugs in software. He's worked on Frama-C before and he is currently working on a new code analyzer tool which is not public yet, but it already found a number of potential issues in OpenSSL.