A security issue in giflib was announced today (December 21): http://openwall.com/lists/oss-security/2015/12/21/4 It says that giflib 5.1.1 is affected, but the same code exists in the giflib 4.2.3 that we have. Mageia 5 is also therefore affected. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA5TOO
Fedora has issued an advisory for this on January 3: https://lists.fedoraproject.org/pipermail/package-announce/2016-January/174870.html Patched packages uploaded for Mageia 5 and Cauldron. Advisory: ======================== Updated giflib packages fix security vulnerability: A heap-based buffer overflow vulnerability was found in giffix utility of giflib when processing records of the type `IMAGE_DESC_RECORD_TYPE' due to the allocated size of `LineBuffer' equaling the value of the logical screen width, `GifFileIn->SWidth', while subsequently having `GifFileIn->Image.Width' bytes of data written to it (CVE-2015-7555). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7555 https://lists.fedoraproject.org/pipermail/package-announce/2016-January/174870.html ======================== Updated packages in core/updates_testing: ======================== giflib-progs-4.2.3-4.1.mga5 libgif4-4.2.3-4.1.mga5 libgif-devel-4.2.3-4.1.mga5 from giflib-4.2.3-4.1.mga5.src.rpm
Version: Cauldron => 5Assignee: bugsquad => qa-bugsWhiteboard: MGA5TOO => (none)Severity: normal => majorURL: (none) => http://lwn.net/Vulnerabilities/670066/
Had to resubmit the build because of a strange build system issue. Updated packages in core/updates_testing: ======================== giflib-progs-4.2.3-4.2.mga5 libgif4-4.2.3-4.2.mga5 libgif-devel-4.2.3-4.2.mga5 from giflib-4.2.3-4.2.mga5.src.rpm
aseprite uses a bundled giflib 5.1, I'll have a look to see if I can use the same patch.
Trying M5 x64 Available info is short: http://giflib.sourceforge.net/intro.html http://giflib.sourceforge.net/giffix.html The list of commands provided by the package is more extensive than in the documentation above. The references refer to giffix, so I concentrated on that. "giffix clumsily attempts to fix truncated GIF images" "giffix â attempt to fix up broken GIFs" Downloaded a small GIF image, and used dd to truncated it: $ dd if=<original.gif> of=<truncated.gif> bs=1 count=<less than original size> Trying with issued packages: $ giffix <truncated.gif> yielded garbage output on the terminal, which stuck. Ctrl/C had no effect; Ctrl/D closed it! Updating to: giflib-progs-4.2.3-4.2.mga5 lib64gif4-4.2.3-4.2.mga5 produced the same result. I am wary of OKing this at this stage.
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #4) > > Downloaded a small GIF image, and used dd to truncated it: > $ dd if=<original.gif> of=<truncated.gif> bs=1 count=<less than original > size> > Trying with issued packages: > $ giffix <truncated.gif> > yielded garbage output on the terminal, which stuck. Ctrl/C had no effect; > Ctrl/D closed it! The help page for giffix says: "The fixed file is dumped to stdout." So the garbage output you got on the terminal was actually your fixed gif file, so you need to redirect it to a file: $ giffix truncated.gif > repaired.gif
(In reply to Rémi Verschelde from comment #5) > > The help page for giffix says: "The fixed file is dumped to stdout." > So the garbage output you got on the terminal was actually your fixed gif > file, so you need to redirect it to a file: > > $ giffix truncated.gif > repaired.gif Hm I could have misinterpreted though, as the full sentence is "If no GIF file is given, giffix will try to read a GIF file from stdin. The fixed file is dumped to stdout.", so maybe it only applies to this very case where the file is read from stdin.
It definitely sounds like the GIF contents were being dumped to stdout, so the output redirection > was the right idea.
Rémi Thanks for your rapid comments. I should have guessed the STDOUT thingy, but I *had* looked beforehand (but clearly not read closely enough the HTML page: $ giffix -h giffix Version 4.2, Gershon Elber, Jan 4 2016, 21:35:57 (C) Copyright 1989 Gershon Elber. Usage: giffix [-v] [-h] GifFile No man entries that I could find. Re-trying... $ giffix artichoke-chocolate10.short.gif > output.gif Following error occured (and ignored): GIF-LIB error: Failed to Read from given file. Following unrecoverable error occured: GIF-LIB error: Failed to Read from given file. Segmentation fault was not very encouraging! As a control, $ display artichoke-chocolate10.short.gif display: corrupt image `artichoke-chocolate10.short.gif' @ error/gif.c/ReadGIFImage/1364. I might try simply corrupting the image rather than chopping it.
Yeah I was thinking that truncating a GIF file with dd was a clever trick, but obviously it alters the file in a way that makes it utter garbage (information is not stored sequentially in such a file IMO, so just removing the last bits probably loses the information bits that close the loop and say "this is a gif file"). The html page about giffix says that it's just a hacky command that adds black space in place of corrupted parts of the gif, I'm not sure you can easily craft a gif on which the tool would be meaningful. It would probably be easier to try commands like http://giflib.sourceforge.net/giftext.html or http://giflib.sourceforge.net/gifhisto.html
As far as I can recall (from 20 years ago) a GIF encoded image starts with a short header announcing what type of file it is with the image dimensions and possibly other data, followed by an RGB colour table of 768 bytes (3*256) and then a continuous stream of run-length-encoded data. I cannot remember there being any flyback markers, just wraparounds. Truncating that would likely corrupt the image. It could in principle still be able to be displayed up to about that point I think (giffix?) but you may be correct about needing to close the loop for standard display software.
CC: (none) => tarazed25
Though, following the web links, the full specification is a lot more complex. The above is what I vaguely remember from coding a display program in assembler for MSDOS.
To aid followers, and in response to Comment 9, here are the commands furnished by giflib-progs (all in /usr/bin/). Those marked * are referenced/described from: http://giflib.sourceforge.net/intro.html and for the rest, $ <command> -h mostly gives the syntax but *not* the use! gif2rgb*, gif2x11, gifasm, gifbg*, gifburst, gifclip, gifclrmp*, gifcolor*, gifcomb, gifcompose, giffiltr, giffix*, gifflip, gifhisto*, gifinfo, gifinter, gifinto*, gifovly, gifpos, gifrotat, gifrsize, gifspnge, giftext*, gifwedge*, icon2gif, raw2gif, rgb2gif, text2gif The intro page also references commands *not* present: gifbuild, gifecho, giftool Notwithstanding this abundance, the bug really appears to relate just to 'giffix'. The library claims to be extensively used and stable, so can be generally trusted. It was already installed on my system, but not the progs.
Testing x64 giflib-progs-4.2.3-4.2.mga5 lib64gif4-4.2.3-4.2.mga5 Trying just corrupting a sample GIF: $ giffix corrupt.gif > output.gif Following error occured (and ignored): GIF-LIB error: Image is defective, decoding aborted. Following unrecoverable error occured: GIF-LIB error: Wrong record type detected. Segmentation fault which again is discouraging. Especially when... $ display corrupt.gif did actually show it! If slightly messed up. Trying a few other commands, all seemingly OK: $ gif2rgb -o rgb.gif original.gif yields correctly 3 output files rgb.gif.B rgb.gif.G rgb.gif.R. $ $ gif2rgb -1 -o rgb.gif original.gif yields just one: rgb.gif $ gifinfo original.gif Size: 80x67 Comment: $ giftext original.gif original.gif: Screen Size - Width = 80, Height = 67. ColorResolution = 8, BitsPerPixel = 8, BackGround = 0. Has Global Color Map. GIF89 graphics control (Ext Code = 249 [ ]): Image #1: Image Size - Left = 0, Top = 0, Width = 80, Height = 67. Image is Non Interlaced. No Image Color Map. Gif file terminated normally. $ gifhisto original.gif > histogram produced a tiny graphic viewable by ImageMagic. Trying: $ gifinfo corrupt.gif GIF-LIB error: Image is defective, decoding aborted. $ gifinfo short.gif GIF-LIB error: Failed to Read from given file. $ gifinfo rgb.gif GIF-LIB error: Given file is NOT GIF file. yields sensible errors, but NO crashes. Which still leaves 'giffix' suspect. If this is deemed acceptable, please OK this update.
I really do want feedback about the unhappy behavious of 'giffix' with both my shortened and simply corrupted images. It is doubtful whether it is reversion, because my Comment 4 re a truncated image file showed similar behaviour before & after the update. Trying it correctly with redirected STDOUT yielded Segmentation fault for both the trimmed & simply corrupted images. 'giffix' does not seem to have improved - although it *may* avoid the security loophole for which it was corrected. I would like to OK this update, but need some encouragement to do so.
x64 Since the behaviour of giffix was similar before & after the update (crashing on deliberately messed up GIF files), and the update is *security* related, I am saying 'no regression' and OKing it.
Whiteboard: (none) => MGA5-64-OK
Whiteboard: MGA5-64-OK => MGA5-64-OK advisoryKeywords: (none) => validated_updateCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0020.html
Status: NEW => RESOLVEDResolution: (none) => FIXED