|Summary:||<app-arch/gzip-1.4, <app-arch/ncompress-220.127.116.11, <dev-libs/liblzw-0.2: Multiple vulnerabilities (CVE-2009-2624,CVE-2010-0001)|
|Product:||Gentoo Security||Reporter:||Alex Legler (RETIRED) <a3li>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||300944|
Description Alex Legler (RETIRED) 2010-01-14 07:23:26 UTC
** 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. CVE-2010-0001 flaw: 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.
Comment 1 Alex Legler (RETIRED) 2010-01-14 07:30:49 UTC
Created attachment 216461 [details, diff] gzip-CVE-2010-0001.patch
Comment 2 SpanKY 2010-01-14 07:58:33 UTC
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.
Comment 3 SpanKY 2010-01-14 07:59:30 UTC
btw, i'm pretty sure the same bug exists in ncompress and liblzw
Comment 4 Alex Legler (RETIRED) 2010-01-14 08:02:18 UTC
(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.
Comment 5 SpanKY 2010-01-14 08:13:18 UTC
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.
Comment 6 Alex Legler (RETIRED) 2010-01-15 17:31:46 UTC
(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.
Comment 7 SpanKY 2010-01-21 05:13:05 UTC
gzip-1.4 now in the tree
Comment 8 Alex Legler (RETIRED) 2010-01-21 13:15:09 UTC
*** Bug 301706 has been marked as a duplicate of this bug. ***
Comment 9 Stefan Behte (RETIRED) 2010-01-24 00:22:12 UTC
What's the plan for CVE-2010-0001?
Comment 10 SpanKY 2010-01-24 01:40:43 UTC
i dont understand the question. the entire point of the [delayed] 1.4 release was to cover CVE-2010-0001.
Comment 11 Stefan Behte (RETIRED) 2010-01-24 14:28:40 UTC
Sorry, then I misunderstood it. I thought we might also want to fix liblzw/ncompress before unrestricting.
Comment 12 SpanKY 2010-01-30 00:11:14 UTC
ncompress-18.104.22.168 is now in the tree
Comment 13 Stefan Behte (RETIRED) 2010-02-06 15:41:07 UTC
CVE-2009-2624 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2624): 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.
Comment 14 SpanKY 2010-02-09 01:19:54 UTC
and now i've gotten around to releasing liblzw-0.2
Comment 15 SpanKY 2010-02-10 06:03:02 UTC
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): app-arch/gzip-1.4 app-arch/ncompress-22.214.171.124 dev-libs/liblzw-0.2
Comment 16 Joe Jezak (RETIRED) 2010-02-10 16:10:14 UTC
ncompress and gzip work fine, marked ppc/ppc64 stable.
Comment 17 Jeroen Roovers 2010-02-10 16:43:51 UTC
Stable for HPPA.
Comment 18 Markus Meier 2010-02-10 21:00:19 UTC
Comment 19 Tiago Cunha (RETIRED) 2010-02-11 00:34:59 UTC
Comment 20 Raúl Porcel (RETIRED) 2010-02-11 19:36:18 UTC
Comment 21 Tobias Heinlein (RETIRED) 2010-03-01 12:18:43 UTC
CVE-2010-0001 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-0001): 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 error.
Comment 22 Tobias Heinlein (RETIRED) 2010-03-01 12:24:09 UTC
Comment 23 Tim Sammut (RETIRED) 2011-03-19 23:01:04 UTC
*** Bug 279387 has been marked as a duplicate of this bug. ***
Comment 24 GLSAMaker/CVETool Bot 2014-12-12 00:20:56 UTC
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).