On Sat, 2 Apr 2016 13:39:53 +0900 Carsten Haitzler (The Rasterman) <[email protected]> said:
> On Sat, 2 Apr 2016 06:48:54 +0300 "Yuriy M. Kaminskiy" <[email protected]> > said: > > > On 02.04.2016 06:21, Yuriy M. Kaminskiy wrote: > > > On 02.04.2016 06:12, Carsten Haitzler (The Rasterman) wrote: > > >> 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? > > > Sorry, bug link is wrong. > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785369 > > > > > >> > > >> so i and j are defined by code so are always >= 0. > > > > > > It is not about i and j. It is about row[i][j]. Which might be more > > > than ColorCount, and *not* verified by giflib. Same applies to > > > SBackGroundColor, it can also trigger out-of-bound reads from cmap. > > > Checks for more than 256 and less than 0 is pure paranoia, but won't > > > harm anyway. > > (... except for `transp`, which *can* be -1, legitimately [and that case > > was *not* broken in current code]). > > see my other reply - i was looking at < 0 cases or for color values to be > beyond 255 etc. as the patch removed a lot of the pixel lookups. it was the <= > 255 > max palette index gap. small and just a dos but > > i wanted to know the core issue because ... i actually don't care about > imlib2 :) that has been dropped from my radar like back in 2003/4 or so... :) > but evas has a gif loader and it does suffer the same issue. i just fixed it > and pushed a patch. > > but i'm alsso distracted by giflib seemingly behaving erratically. i think. > like an image (gif image) had parse errors if you load it off the bat - run > the app for a while then load and it loads FINE later... giflib itself is > complaining of gif errors in the file decode... it seems.. i think i may have > hit on a libgif issue - buty i am not sure. i am certain our gif loader worked > fine the last time i heavily checked it and it hasnt changed in years > really... so why would it fail now? something else is up. yup. giflib 5 bug. found. fixed (or at least reported with patch fix). :) https://sourceforge.net/p/giflib/bugs/94/ > > [...] > > >> 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 > > > > No, it is the case someone (not me, fwiw) using valgrind to detect how > > libraries handles fuzzied files, and found real bugs. > > > > >> 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 > -- ------------- 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
