Fuzzing: Specially crafted input file results in repeatable crash when compiled with ASAN under Ubuntu/GCC. Allows for limited, controlled OOB read.

[ghost]

I found Leanify while doing some research and decided to use Radamsa to test the robustness of the application. It appears pretty solid. I grabbed a ton of test files and then ran this simple loop to generate some more files; for i in $(ls); do cat $i | radamsa; done.

I did note a few things that were interesting, the most of which was a crash noted by ASAN from mutated files that proved hard to debug. I've done the test case reduction already down from several hundred bytes to the smallest byte string I could find that still induced the crash.

I did note that by modifying the length of the input file, the resulting address of the crash could be changed. Note that in the reproduction steps below, amongst the output shows the READ attempt at crash time. Another interesting crash I noted was a WRITE of 1024 bytes in another crash file. //Cleaning up stack traces.

[JayXon]

Thanks for the report, I always wanted to do some fuzzing. Could you upload a file that could reproduce the crash? For symbol, by default the Makefile strips debug information, maybe try remove -s from Makefile and recompile?

[ghost]

Performed root cause analysis on repeatable crash.

PNG.cpp allows for an OOB read with a specially crafted file with limitations.

[ghost]

The address of the read can be controlled by crafting the file so that chunk_length, memory location of p_read, and 0xFFFFFFFF are guessed relative to the desired location. Unsure if the memory can be retrieved from the segfault.

A non-specially crafted example of this is here, pasted in base64:

root@X:~/clones# cat id:000003,sig:11,src:012690,op:flip32,pos:14 | base64 AAABAAEAAAAAAAAAAAD/////CQAAAACA

[JayXon]

This particular issue with ico should be fixed now, let me know if you can find other crash.

[ghost]

Controllable size read/write issue fixed in new commit. Closing issue.