** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **
Jan Lieskovsky informed us about the following vulnerabilities:
CVE-2009-2624 flaw (re-appearance of CVE-2006-4334):
A missing input sanitation flaw was found in the way gzip used to decompress
data blocks for dynamic Huffman codes. This could result in arbitrary code execution/DoS (crash).
This is already fixed in the 1.3.14 in ~arch.
Aki Helin found an integer overflow leading to array index error in
the way gzip used to decompress files / archives, compressed with
the Lempel–Ziv–Welch (LZW) compression algorithm. This issue is specific to 64-bit systems, also possibly resulting in ACE/DoS.
I'll attach a patch for this issue, please prepare an updated ebuild. If you don't want to base it on 1.3.14, I can also provide a patch for the first issue.
Created attachment 216461 [details, diff]
there hasnt been any bugs about gzip-1.3.13 or gzip-1.3.14, and they're plenty past the 30 day limit. so i've run a stabilization bug for fun.
btw, i'm pretty sure the same bug exists in ncompress and liblzw
(In reply to comment #2)
> there hasnt been any bugs about gzip-1.3.13 or gzip-1.3.14, and they're plenty
> past the 30 day limit. so i've run a stabilization bug for fun.
Er, the second issue is /not/ fixed in 1.3.14.
sorry, i misread the summary. CVE-2010-0001 def applies to liblzw/ncompress since pretty much everyone took the lzw implementation from the same place. it'll be some time before i can put out new versions of those packages though.
(In reply to comment #5)
> sorry, i misread the summary. CVE-2010-0001 def applies to liblzw/ncompress
> since pretty much everyone took the lzw implementation from the same place.
> it'll be some time before i can put out new versions of those packages though.
Can we get at least an updated gzip ebuild now? There are 5 more days I'd like to use for prestabling. Thanks.
Update for CVE-2010-0001: The issue is an integer underflow, not overflow.
gzip-1.4 now in the tree
*** Bug 301706 has been marked as a duplicate of this bug. ***
What's the plan for CVE-2010-0001?
i dont understand the question. the entire point of the [delayed] 1.4 release was to cover CVE-2010-0001.
Sorry, then I misunderstood it. I thought we might also want to fix liblzw/ncompress before unrestricting.
ncompress-18.104.22.168 is now in the tree
The huft_build function in inflate.c in gzip before 1.3.13 creates a
hufts (aka huffman) table that is too small, which allows remote
attackers to cause a denial of service (application crash or infinite
loop) or possibly execute arbitrary code via a crafted archive.
NOTE: this issue is caused by a CVE-2006-4334 regression.
and now i've gotten around to releasing liblzw-0.2
arch teams: we have gzip that should stabilize (it is known to crash). there is also ncompress and liblzw that have the same code, but no known crash vectors.
so to put it simply, please stabilize (if applicable):
ncompress and gzip work fine, marked ppc/ppc64 stable.
Stable for HPPA.
Integer underflow in the unlzw function in unlzw.c in gzip before 1.4
on 64-bit platforms allows remote attackers to cause a denial of
service (application crash) or possibly execute arbitrary code via a
crafted archive that uses LZW compression, leading to an array index
*** Bug 279387 has been marked as a duplicate of this bug. ***
This issue was resolved and addressed in
GLSA 201412-08 at http://security.gentoo.org/glsa/glsa-201412-08.xml
by GLSA coordinator Sean Amoss (ackle).