Hi Helmut, On Sat, Dec 03, 2022 at 09:31:42AM +0100, Salvatore Bonaccorso wrote: > Hi Helmut, > > > On Sat, Jan 02, 2021 at 01:35:09PM +0100, Salvatore Bonaccorso wrote: > > > Looks the wrong bug was closed here? CVE-2018-11490 was sf#113, while > > > this one is CVE-2018-11489, sf#112, which does not seem to be adressed > > > yet (altough the upstream report disapeared). > > > > I looked into this and think this is fixed. > > > > Since the issue disappeared, all we have is the vulnerability > > description: > > > > | The DGifDecompressLine function in dgif_lib.c in GIFLIB (possibly > > | version 3.0.x), as later shipped in cgif.c in sam2p 0.49.4, has a > > | heap-based buffer overflow because a certain CrntCode array index > > | is not checked. This will lead to a denial of service or possibly > > | unspecified other impact. > > > > Looking into DGifDecompressLine, the offending CrntCode is obtained > > using DGifDecompressInput. If you look how that value is assigned, one > > of the CodeMasks is always used to assign it. The maximum mask is 0xfff > > or 4095. So we're using this number to index into the Prefix array, > > which is statically sized LZ_MAX_CODE + 1 == 4096. This all seems fine > > to me. > > > > Looking into sam2p, we can see stefan-cornelius proposed a patch: > > https://github.com/pts/sam2p/files/2252965/sam2p_CVEs.patch.txt > > > > This patch adds the code that ensures that DGifDecompressInput never > > yields a value exceeding the maximum mask and I see how it addresses the > > vulnerability quoted earlier. It has been applied even to jessie and is > > present since the git history of giflib. > > > > As such, I conclude that sam2p was shipping a very old fork of giflib > > and giflib has fixed this way longer ago. > > > > I'm also going to update the security tracker. > > Thanks for the analysis. Were you able to pin point the giflib version > historically fixing this, I suggest to use debsnap to look at > dgif_lib.c code as one possibility and track which unstable upload was > it which fixed it. > > Then you can use this as the fixing version (if it's not pre-initial > upload, otherwise not-affected, and fixed before initial release), and > then drop all the no-dsa tagged entries which are not relevant.
It did that exercise, and please double check: But the change should have landed in 4.1.4 upstream. I compared 3.0-6 and 4.1.4-1 then which landed in the Debian archive, which contains the patch you mentioned. Regards, Salvatore
