A bzip2 security issue was reported to Debian security team: Mikołaj Izdebski has discovered an integer overflow flaw in the BZ2_decompress function in bzip2/libbz2. An attacker could use a crafted bz2 file to cause a denial of service (application crash) or potentially to execute arbitrary code. (CVE-2010-0405)
Created attachment 441451 [details] Proposed patch
Created attachment 448401 [details] bzip2 1.0.5 -> 1.0.6 diff Fix added in bzip2 1.0.6 additional extra sanity checks compared to previously proposed patch.
Public now via bzip2 1.0.6 release.
CCing clamav maintainers, clamav contains embedded copy of bzip code in libclamav/nsis/bzlib.c .
This issue has been addressed in following products: Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 Via RHSA-2010:0703 https://rhn.redhat.com/errata/RHSA-2010-0703.html
(In reply to comment #9) > CCing clamav maintainers, clamav contains embedded copy of bzip code in > libclamav/nsis/bzlib.c . This is now fixed in clamav upstream version 0.96.3. Upstream commit: http://git.clamav.net/gitweb?p=clamav-devel.git;a=commitdiff;h=fcd8091474d12592d509adcfd0bdd0b0dc8835f5#patch4
Clamav shouldn't need to be updated because of this. libclamav uses libbz2, and there are buildrequires on bzip2-devel so it should not be using it's internal bzip2 copy at all.
I admit I may be wrong here, or confused by a report mentioning this embedded bzip code copy in clamav. Looking at the build.log, libclamav/nsis/bzlib.c is compiled when building Fedora clamav packages and does not contain any #ifdefs to wrap system libbz2. libclamav links system libbz2 and does use it to decompress bz2 files. nsis/bzlib.c only seems to be used by nsis (Nullsoft Scriptable Install System) unpacker. Corrections welcome.
Sorry, looks like you may be right after all. I'm not sure why it links to libbz2 and also contains this bzlib.c. At any rate, yes, clamav should be updated to correct this as it does not look as though the system libbz2 changes will have any impact there. Sorry for adding to the confusion.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2010:0858 https://rhn.redhat.com/errata/RHSA-2010-0858.html
I think it's time to move the patch from Fedora 12 updates-testing repository to Fedora 12 updates repository. Updates-testing repository is not enabled by default, so I suppose that a lot of Fedora 12 users are still affected by this security problem.