[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

zlib status (CAN-2005-2096)

As far as I know, we currently have the following set of bugs related
to the recent zlib vulnerability:

  309196   rageircd           (proactively filed, reused for CAN-2005-2096)
  317523   aide
  317966   dump
  317967   dpkg
  317968   zsync
  317970   amd64-libs         (private copy of DSO)
  317971   ia32-libs          (private copy of DSO)
  317989   dar-static         (deliberately linked statically)
  318014   bacula-sd
  318069   sash
  318091   libphysfs-1.0-0    (missing build dependency)
  318096   mrtg
  318097   oops
  318099   lsb-rpm
  318100   texmacs            (alpha only, probably buildd problem)
  318101   systemimager-ssh   (private copy of DSO)

Most of those zlib copies were discovered by Christoph Biedl, who ran
clamscan on the Debian mirror of the Computing Centre of FU Berlin
(Hochschulrechenzentrum, ZEDAT).  Thanks Christoph for scanning a
whopping 650 GB of data (uncompressed)!  Also thanks to Kurt Roeckx,
who filed some of the other bugs.

Not all of these bugs are indeed exploitable because some of the
packages trust the input anyway, but if this the case is sometimes
hard to tell without being familiar with the package.  I hope the
individual package maintainers can provide clarification.

I didn't file any bugs for Windows binaries included in some packages
which might have vulnerable code (Python distutils, for example).
Input data for them seemed to be trusted, anyway.

How shall we fix these bugs in stable and oldstable?  zlib1g is
already installed on most systems, so it should be reasonably safe to
link dynamically against the system-wide zlib library.  We only change
programs which use zlib 1.2.x, so the code change is not substantial,
either.  In very few cases, static linking will continue (dar-static),
and these packages must be recompiled against the fixed version of

Reply to: