Open retpoline opened 2 years ago
I don't know that this is actually a problem; anyway I'd like to see more explanation. What's happening is that the realloc
call is failing, likely because this bogus GIF claims to be ~40000x50000px, and an allocation attempt of that size fails. But Gifsicle is prepared for the allocation to fail.
When I run this gif with sanitizers, no access problems are reported. There was an UB related to integer overflow, but I've fixed that in a commit (and I doubt it was exploitable).
Hmm integer overflow somewhere along the way makes sense.
Regardless, thanks for the fix!
To be clear, I believe you will still get a report like the above.
I see. Perhaps a check or warning for a less-than-sane pixel size?
Hi folks,
An interesting crash was found while fuzz testing of the gifsicle binary which can be triggered via a malformed GIF file. Although this malformed file only crashes the program as-is, it could potentially be crafted further and create a security issue where these kinds of files would be able compromise the process's memory through taking advantage of affordances given by memory corruption. It's recommend to harden the code to prevent these kinds of bugs as it could greatly mitigate such this issue and even future bugs.
crash.gif (base64 encoded due to file format)
debug log
(requires the electric fence malloc debugger library to instrument the memory manager to find the subtle crash: sudo apt-get install electric-fence)
Thanks!