GNOME Bugzilla – Bug 758315
GIF extractor crashes on maliciously crafted gif
Last modified: 2016-10-09 13:15:46 UTC
If this file: https://github.com/php/php-src/blob/master/ext/gd/tests/bug37360.gif Is saved on the system, tracker-extract (1.6.0) will crash, I see giflib is used so my relevant version of that is 4.2.3. It looks like it's trying to allocate ~16 EiB of memory to extract that gif on my system.
Created attachment 326198 [details] another sample image causing this This is an image (id:000245,src:000000,op:havoc,rep:4.gif) from the American Fuzzy Lop suite (http://lcamtuf.coredump.cx/afl/demo/) that is causing the same crash for me as the image referenced above. Backtrace: Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff6824183 in _g_log_abort (breakpoint=1) at gmessages.c:325 325 G_BREAKPOINT (); (gdb) bt
+ Trace 236187
Created attachment 326200 [details] [review] patch proposal The fault is a signed integer overflow that occurs when the memory for the image data is about to be malloc'd. Although the crash itself could be avoided by switching to g_malloc_n() it would overflow again afterwards when calling the giflib. This patch tries to avoid both overflows by reading/skipping over the image data line by line. This might be a bit slower but besided avoiding the overflow also avoids tracker allocating close to 4GB of memory in the worst case (which could cause an abort() or OOM kill again).
Comment on attachment 326200 [details] [review] patch proposal Thanks so much for the patch :). I see nothing wrong with it really, although I'm ultimately wondering why do we bother to read pixel data from the gif, it's effectively going nowhere, and I'd trust libgif gives up earlier than that on not-quite-gifs.
Thanks to both for the sample images btw, they're going to my test folder.
(In reply to Carlos Garnacho from comment #3) > Comment on attachment 326200 [details] [review] [review] > patch proposal > > Thanks so much for the patch :). I see nothing wrong with it really, > although I'm ultimately wondering why do we bother to read pixel data from > the gif, it's effectively going nowhere, and I'd trust libgif gives up > earlier than that on not-quite-gifs. I was wondering about that too and IIRC it turned out that giflib reads GIFs sequentially and to skip the frame data to the next data block (next frame, metadata?,...) one has to "consume" it. Not sure if there's a way to do it without decompressing the image though.
Comment on attachment 326200 [details] [review] patch proposal Ugh, APIs from the 80s... :). I tested here and that's indeed the case, so this is fine to go. Thanks again for the patch :)
*** Bug 749137 has been marked as a duplicate of this bug. ***
Thanks for the review Carlos. :) I pushed the fix to master. Would it be possible to cherrypick it for 1.8 and maybe even 1.6 (not sure about 1.4; that branch seems active as well)? commit 369fdc9c1c1c1c8bb74b6dcb3a095392c40e0526 Author: Felix Riemann <> Date: Sun Apr 17 15:42:38 2016 +0200 tracker-extract-gif: Avoid possible integer overflow Fix integer overflow when skipping over the decoded image data of extremely large or specifically prepared images. https://bugzilla.gnome.org/show_bug.cgi?id=758315 --- This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.
(In reply to Felix Riemann from comment #8) > Thanks for the review Carlos. :) > I pushed the fix to master. Would it be possible to cherrypick it for 1.8 > and maybe even 1.6 (not sure about 1.4; that branch seems active as well)? It indeed makes sense to backport this patch. I'll take care of that when doing releases. There should be at least a 1.8 one soon :).
*** Bug 771184 has been marked as a duplicate of this bug. ***