A heap buffer overflow vulnerability was found in giflib. A maliciously crafted gif file could cause the application to crash. External references: https://sourceforge.net/p/giflib/bugs/87/ Upstream fix: https://sourceforge.net/p/giflib/code/ci/ea8dbc5786862a3e16a5acfa3d24e2c2f608cd88/ References: http://bugs.fi/2016-03-gif2rgb.txt http://bugs.fi/media/afl/giflib/1.gif
Created giflib tracking bugs for this issue: Affects: fedora-all [bug 1325772]
The palette of the image has only 2 colors, but the background color is set to an index value of 255, which, in this case, is outside the range of valid values. The main() function sets the background image value when filling up the screen buffer: (line numbers for RHEL7) 148 for (i = 0; i < GifFile->SWidth; i++) /* Set its color to BackGround. */ 149 ScreenBuffer[0][i] = GifFile->SBackGroundColor; Later, in the DumpScreen2RGB function, it tries to look up the background color within the palette: 292 GifRow = ScreenBuffer[i]; 293 GifQprintf("\b\b\b\b%-4d", ScreenHeight - i); 294 for (j = 0, BufferP = Buffer; j < ScreenWidth; j++) { 295 ColorMapEntry = &ColorMap->Colors[GifRow[j]]; 296 *BufferP++ = ColorMapEntry->Red; 297 *BufferP++ = ColorMapEntry->Green; 298 *BufferP++ = ColorMapEntry->Blue; GifRow[j] can be the background color index (255), which is not inside the limits of the ColorMap->Colors array. Subsequent processing leads to out-of-bounds reads, but they should not be dangerous (worst case is a crash). Additionally, as far as I can tell, the giflib library itself is not vulnerable to this attack, only the gif2rgb utility.
Statement: Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.