New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fuzzing: Specially crafted input file results in repeatable crash when compiled with ASAN under Ubuntu/GCC. Allows for limited, controlled OOB read. #50
Comments
|
Thanks for the report, I always wanted to do some fuzzing. |
|
Performed root cause analysis on repeatable crash. PNG.cpp allows for an OOB read with a specially crafted file with limitations. |
|
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 |
|
This particular issue with ico should be fixed now, let me know if you can find other crash. |
|
Controllable size read/write issue fixed in new commit. Closing issue. |
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.
The text was updated successfully, but these errors were encountered: