Bonjour! I did and am currently doing some researches on fuzzing. By just skimming the abstract of several recent fuzzing papers, you may notice the following pattern: “The experimental results showed that our tool ABC outperforms existing fuzzers XYZ and could find @#$ previously unknown crashes in several security-critical projects”. Basically, there are two parts in the evaluation (1) compare with state-of-the-art fuzzers like AFL and (2) fuzz some projects to get CVEs. OK, I follow exactly this method, meaning try to fuzz these projects using my fuzzer that is built on top of BINSEC and AFL. I found and reported two bugs (#5 and #6) of gif2png that converts files from GIF to PNG. This program was used in the evaluation of VUzzer [NDSS’17]. The author Eric S.Raymond has recently fixed these bugs. Right after that, Matthew Garrett – a security @Google twitted and mentioned about the bug #5:

I am not sure why this status has become a bit hot on Twitter maybe because (1) both Matthew and Eric are famous developers and (2) the funny way Eric “fixed” this bug. Is fuzzing really useless since developers seem to be too busy and reluctant to fix bugs due to malformed inputs or just simply ignore them? I think NO. Rohan also shared his thought: “I’ve found library developers to be more likely to address corner-case inputs than developers of end-user applications”, thanks, Rohan! This guy actually gave me some motivational words, thanks, Neil!

I recently found (by fuzzing of course) and reported two bugs (#135 and #136) of the open-source project GIFLIB (commit 866ea06 - v5.1.9) – a library for reading and writing gif images on SourceForge. Interestingly, this project is also maintained by Eric :). Take on look on #136 which is a stack buffer overflow in the utility gifcolor. You can easily pinpoint the root cause and generate a PoC (e.g., python -c "print ' 0 255 255 255\n'*1000" | ./gifcolor) by looking at the source code of the main function in gifcolor.c. In line 47, the array ScratchMap is initialized with length 256. However, there is no sanity check of ColorMapSize when program reads a color map file as input line by line with the dangerous function fscanf() inside the loop (lines 81 - 88). I am not sure why the maximum number of lines of a color map is set to 256 by developers. However, in any case, a check should be added to make the program more robust.

It is obvious that maintainers could easily fix these two bugs. However, I just imagine other two possible cases: (1) Eric will import the SIGSEGV handler he implemented in gif2png into GIFLIB to bail out meaningless fuzzing inputs (2) Eric will simply ignore them. Stay tuned :).

Update (Jun 23, 2019): I don’t know whether Eric read my blog or not, but, he recently confirmed and fixed the bug #136 in a normal way. In addition, more discussion is needed for the bug #135.

Update (Jun 24, 2019): I can reproduce the null pointer dereference bug #135 in the version 5.2.0 (commit d5cd5d0) while Eric can’t reproduce the crash on his side. More specifically, the pointer SColorMap is NULL in sanity checks that have been added to fix the bug #87 as mentioned in the comment. Therefore, it could be considered as regression bug (a.k.a, incompleted patch). Finally, Eric accepted my proposed patch to fix this problem and release the version 5.2.1. Thanks, Eric!

Update (Jun 28, 2019): Eric released the version 3.0.0 of gif2png a few days ago by porting codes to Golang. TODO: Anyone wants to use gofuzz to fuzz his code?

Happy fuzzing :-P