Summary: | <app-arch/gzip-1.4, <app-arch/ncompress-4.2.4.3, <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> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | normal | CC: | rbu | ||||
Priority: | High | ||||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | A2 [glsa] | ||||||
Package list: | Runtime testing required: | --- | |||||
Bug Depends on: | 300944 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Alex Legler (RETIRED)
2010-01-14 07:23:26 UTC
Created attachment 216461 [details, diff]
gzip-CVE-2010-0001.patch
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-4.2.4.3 is now in the tree 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. 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): app-arch/gzip-1.4 app-arch/ncompress-4.2.4.3 dev-libs/liblzw-0.2 ncompress and gzip work fine, marked ppc/ppc64 stable. Stable for HPPA. amd64/arm/x86 stable sparc stable alpha/ia64/m68k/s390/sh stable 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. Request filed. *** 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). |