On Sat, 02 Apr 2016 04:49:08 +0300 [email protected] (Yuriy M. Kaminskiy) said:
> As reported on http://bugs.debian.org/734425, when ColorCount is less > than 256, it is possible that image loading will trigger out of bound > read. > Security imlications: DoS (application crash), potentially host memory > exposure. > Attached patch(es) gracefully handles out-of-range image data, out-of-range > background and transparent colors, and make code a bit simplier and > faster. ummm can you explain how this actually CAN happen? and the debian bugzilla entry you point it is just discussing patches to imlib2-config etc. - not this patch or security issues that i can see... so red herring? wrong link? so i and j are defined by code so are always >= 0. rows[i][j] does a fetch of pixel value at that row i and x position (j) and this is with giflib headers an unsigned char. so it can never be < 0. bg comes from SBackGroundColor which is an int in giflib api, but if you check the gif format specs, the background color index is a byte - and it's obviously an unsigned byte otherwise indexes >= 128 would be impossible to access... now ColorCount ... how can this be > 256 or < 0? gifg specs allocate 3 bits to color table size. this defines the numebr of BITS for the color table, so can contain values 0 to 7 or mapping really to # of buts being 1 to 8 bitss for color table. so 2, 4, 8, 16, 32, 64, 128 or 256. this colorcount should never be < 2 or > 256 by specifications of the file format and giflib handling of it. are you saying giflib has bugs where it sometimes provides junk for the bg color or colorcount since the c type allows values outside the range? give the actual file format itself there simply is no space in the format to create an exploit. at least not what i'm reading from your patch and from giflib headers and from gif file format specs. so if there is an issue that i am not looking at - can you point it out? this almost smells of someone having uses static analysis tools finding variables that allow negatives (ints) where usage only uses a subset (0 to 255 or 2 to 256) and going "ooh bug bug bug bug! security issue" and not digging a little deeper. :) if this is the case - bravo on actually using tools and doing this. these are possible bug vectors, but given all the other constraints, this is not an issue. you'd be RIGHT if a gif format file used an int for the colorcount and the parser didn't specifically check ranges (giflib would be the place to put this). :) see: https://www.w3.org/Graphics/GIF/spec-gif89a.txt http://giflib.sourceforge.net/gif_lib.html http://giflib.sourceforge.net/gif_lib.html -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
