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
zlib.
Reply to: