| Summary: | <app-arch/bzip2-1.0.6: Integer overflow in decompress.c (CVE-2010-0405) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Dirkjan Ochtman (RETIRED) <djc> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | base-system, kfm |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.cert.fi/en/reports/2010/vulnerability408516.html | ||
| Whiteboard: | A2 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Dirkjan Ochtman (RETIRED)
2010-09-20 18:41:33 UTC
We need a version bump first. :)
@base-system: A rename to 1.0.6 works with the exception of the ${PN}-1.0.4-saneso.patch doesn't apply anymore. If you s/1.0.4/1.0.6/g in the patch, it works and builds. I did not runtime test.
bzip2 (1.0.5-1ubuntu1.1) jaunty-security; urgency=low
* SECURITY UPDATE: fix integer overflow in BZ2_decompress()
- decompress.c: return error if N is larger than 2*1024^2 which keeps es
from overflowing but leaves enough room for the 900k maximum value of
the RUNA/RUNB encoding
- patch from upstream
- CVE-2010-0405
-- Jamie Strandboge Thu, 09 Sep 2010 10:16:51 -0500
also in openbsd
ListWare
* Subscribe openbsd-ports
* Support and FAQ
Home - openbsd - openbsd-ports - 201009 - Thread
security update: archivers/bzip2 1.0.6 CVE-2010-0405
by roberthon 2010-09-20T16:32:12+00:00
* Previous thread: UPDATE: net-snmp
* Next thread: Security: archivers/bzip2
* Threads sorted by date: openbsd-ports 201009
Index: archivers/bzip2/Makefile
==================================================================RCS file: /cvs/ports/archivers/bzip2/Makefile,v
retrieving revision 1.57
diff -u -p -u -p -r1.57 Makefile
COMMENT= block-sorting file compressor, unencumbered
-VERSION= 1.0.5
+VERSION= 1.0.6
DISTNAME= bzip2-${VERSION}
CATEGORIES= archivers
MASTER-SITES= ${HOMEPAGE}${VERSION}/
@@ -15,6 +15,8 @@ PERMIT-PACKAGE-CDROM= Yes
PERMIT-PACKAGE-FTP= Yes
PERMIT-DISTFILES-CDROM= Yes
PERMIT-DISTFILES-FTP= Yes
+
+REVISION= 0
WANTLIB= c
BZ2-CFLAGS= -Wall -Winline
Index: archivers/bzip2/distinfo
==================================================================RCS file: /cvs/ports/archivers/bzip2/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
Re: security update: archivers/bzip2 1.0.6 CVE-2010-0405
by roberthon 2010-09-20T17:10:58+00:00.
Removed unnecessary REVISON, as pointed out by Markus Lude.
Index: archivers/bzip2/Makefile
==================================================================RCS file: /cvs/ports/archivers/bzip2/Makefile,v
retrieving revision 1.57
diff -u -p -r1.57 Makefile
COMMENT= block-sorting file compressor, unencumbered
-VERSION= 1.0.5
+VERSION= 1.0.6
DISTNAME= bzip2-${VERSION}
CATEGORIES= archivers
MASTER-SITES= ${HOMEPAGE}${VERSION}/
Index: archivers/bzip2/distinfo
==================================================================RCS file: /cvs/ports/archivers/bzip2/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
the summary says "<=1.0.6". should it perhaps say "<1.0.6" ? bzip-1.0.6 now in the tree Can we do speedy stabilization? Arches, please test and mark stable: =app-arch/bzip2-1.0.6 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" amd64 done Stable for PPC. Stable for HPPA. Archtested on x86: Everything fine. Let's get going. (In reply to comment #10) > Archtested on x86: Everything fine. Let's get going. > My x86 chroot reports the same. Thanks for testing. x86 stable. (In reply to comment #11) > (In reply to comment #10) > > Archtested on x86: Everything fine. Let's get going. > > > > My x86 chroot reports the same. Thanks for testing. > x86 stable. > And a third person from x86 confirming that it is ok. ;) I wonder how many packages there are that link in libz2 statically, or have the option of doing so. One pertinent example would be app-arch/pbzip2 which has a "static" USE flag. Does anyone agree that it would be worth issuing a revision bump for pbzip2 with a DEPEND on ">=app-arch/bzip2-1.0.6" for the sole purpose of ensuring that those using statically built versions are covered by way of a routine upgrade? If necessary I can give you at least a vague idea about that… but as I said it's vague. Here's a full list of packages which depend on app-arch/bzip2 that may be built statically, if anyone is interested. There may be a few false positives as I'm not in a position to verify that each of these actually links in libbz2, as opposed to just calling upon the bzip2 application. app-arch/dump app-arch/libarchive app-arch/pbzip2 app-crypt/gnupg dev-libs/libpcre media-gfx/imagemagick media-libs/coin media-video/ffmpeg sys-block/partimage sys-cluster/cluster-glue if a package is always linking statically, that's a bug and you should open one as for people doing USE=static, that isnt our concern for today and it isnt specific to USE=bzip2 arm stable Stable on alpha. ppc64 stable CVE-2010-0405 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-0405): Integer overflow in the BZ2_decompress function in decompress.c in bzip2 and libbzip2 before 1.0.6 allows context-dependent attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted compressed file. ia64/m68k/s390/sh/sparc stable GLSA request filed. Presumably this can be closed? This issue was resolved and addressed in GLSA 201301-05 at http://security.gentoo.org/glsa/glsa-201301-05.xml by GLSA coordinator Stefan Behte (craig). |
