Upcoming release fixes bzlib security issue

Clamav won't give out pre-release patches, but suggests since it's an issue in their embedded bzlib, we might be able to get it from bzlib upstream to have packages ready to get.

Can we build clamav against the system bzlib instead?

Got the answer:

<ScottK> aCaB: Our packages are already using the system bzip2? If not, can they?
<aCaB> they are using both
<aCaB> system bzip2 for bzip compression
<aCaB> hacked bzip2 from sources, for hacked bzip compression
<aCaB> latter is in use by certain packers
<aCaB> both are vulnerable anyway
<aCaB> btw it's CVE-2010-0405

Disclosure has been postponed until September 13th.

Since we have the same version to start from in -backports, I would recommend when this is released (I understand there's a second, PDF related vulnerability fix in the next clamav release too) doing one patch to the current backports packages and promoting them to -security.

It will not require any other packages to be updated.

    clamav | 0.96.1+dfsg-3ubuntu5~dapper1 | dapper-backports/universe | source, amd64, i386, powerpc
    clamav | 0.96.1+dfsg-3ubuntu5~hardy1 | hardy-backports/universe | source, amd64, i386
    clamav | 0.96.1+dfsg-3ubuntu5~jaunty1 | jaunty-backports | source, amd64, i386
    clamav | 0.96.1+dfsg-3ubuntu5~karmic1 | karmic-backports | source, amd64, i386
    clamav | 0.96.1+dfsg-3ubuntu5~lucid1 | lucid-backports | source, amd64, i386
    clamav | 0.96.1+dfsg-3ubuntu5 | maverick | source, amd64, i386

The only hole is Hardy lpia. It's in Universe so it's not essential, but I'd like to try to build without llvm support. I didn't quite manage it yet.

Scott, I have the upstream bzip2 patch now and can patch clamav for supported releases (I'll even throw in Dapper and Hardy this time, since it is a small patch). Is there a compelling reason to move to 0.96.1 on all releases at this time? You mentioned the PDF fix-- do you have a patch for it?

I don't have it. Clamav doesn't pre-release patches to vendors (or at least not that they are willing to admit to me).

The move to 0.96.1 would get all releases on one code base and (at least in theory) be easier. In general, this is how we've proceeded in the past. This one will be easier since 0.95 -> 0.96 is an ABI compatible jump.

Sure. The difference is of course the amount of testing required (as you know). I think I'd prefer to wait on the jump to 0.96.1 until there is a compelling reason to do so, though I am still open to the idea if you feel strongly that it is warranted.

Uploaded updated maverick package (0.96.1+dfsg-3ubuntu5.1) to the security PPA since it is still not public. I used the upstream bzip2 patch for this.

Still not published from upstream bzip2. I will mark this bug public when they release bzip2 1.0.6.

This bug was fixed in the package clamav - 0.96.1+dfsg-3ubuntu5.1

---------------
clamav (0.96.1+dfsg-3ubuntu5.1) maverick; urgency=low

  * SECURITY UPDATE: fix integer overflow in BZ2_decompress()
    - libclamav/nsis/bzlib.c: return error if N is larger than 2*1024^2 which
      keeps us from overflowing but leaves enough room for the 900k maximum
      value of the RUNA/RUNB encoding
    - patch based on upstream bzip2
    - LP: #625849
    - CVE-2010-0405
 -- Jamie Strandboge <email address hidden> Mon, 13 Sep 2010 14:44:01 -0500

This issue is now public, but since I don't know if the PDF issue is public, leaving as private for now.