Bug 152775 - CAN-2004-0797 - Zlib Compression Library Denial Of Service Vulnerability
Summary: CAN-2004-0797 - Zlib Compression Library Denial Of Service Vulnerability
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: zlib
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Fedora Legacy Bugs
QA Contact:
URL: http://www.securityfocus.com/bid/11051
Whiteboard: 1, LEGACY
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-02 08:29 UTC by Tobias Sager
Modified: 2007-03-27 04:29 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2005-05-16 10:34:47 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 131385 None None None Never

Description David Lawrence 2005-03-30 23:27:01 UTC

Vulnerable: <=zlib-1.2.1
Patch at:   ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.5/common/017_libz.patch

------- Additional Comments From marcdeslauriers@videotron.ca 2004-09-08 11:49:42 ----

zlib versions older than 1.2 are not affected.

rh7.3 and rh9 are therefore not affected by this bug.


------- Additional Comments From fedora-legacy-bugzilla-2004@fumika.jp 2004-11-09 17:52:41 ----

Fedora Core 1 is affected of this issue.

------- Additional Comments From rob.myers@gtri.gatech.edu 2004-11-19 08:50:50 ----

Hash: SHA1
Here is an updated zlib packages to QA for fc1:
- - should fix CAN-2004-0797
- - uses the patch, available from 2 places:
- - are there other programs that have incorporated vulnerable zlib code?
* Fri Nov 19 2004 Rob Myers <rob.myers@gtri.gatech.edu>
- - apply patch for CAN-2004-0797 (FL #2043)
c74105d2dfa35c895c616900089c3d3a9d80633b  zlib-
b6100a90dc182b7a6b9a676cb39103a6a84bc4bf  zlib-
01e2da015548e73e4f7d131943d943030f2e5fa3  zlib-debuginfo-
056c6e797c5b032fb8c1b58c5ff8ec39261bc871  zlib-devel-
Version: GnuPG v1.2.3 (GNU/Linux)

------- Additional Comments From deisenst@gtw.net 2004-11-24 09:40:22 ----

Hash: SHA1

I did QA on Rob's zlib FC1 package.

b6100a90dc182b7a6b9a676cb39103a6a84bc4bf  zlib-

  * sha1sum ok
  * PGP signature on Rob's key okay
  * source file okay (compared to zlib-
  * spec file looks great
  * patch for CAN-2004-0797 looks good; comparable to patch in RH Bugzilla 
  * Builds well.
  * rpm-build-compare script output looks reasonable
  * installs okay
  * runs okay.  Tested it debug/running lynx retrieving gzip-deflated
    webpages from an Apache webserver with mod_deflate activated.

   PUBLISH+		-David
Version: GnuPG v1.2.3 (GNU/Linux)


------- Additional Comments From deisenst@gtw.net 2004-11-24 09:47:01 ----

Hash: SHA1

One concern I have is this:  Are there any FC1 packages that link in zlib
statically?  If there are, I am wondering if those will need recompiling/
linking with this new zlib to ensure they will be free of the DoS?

The OpenPKG advisory [OpenPKG-SA-2004.038-zlib], says this:
  Additionally, rebuild and reinstall any other dependent packages (see
  above) already installed in your OpenPKG instance. Only updating the
  "zlib" package is NOT sufficient because of the statically linked old
  "libz.a" code residing in the executables of other dependent packages.

That advisory listed a bunch of OpenPKG packages they consider dependent.
On my own FC1 system, I find binaries (grep "inflate Copyright 
1995-2003 Mark Adler") from these packages appear to have the
inflate portion of libz.a statically linked in:

    * modutils-2.4.25-13  
         binaries: /sbin/{depmod,insmod,insmod.static,modinfo}
    * dump-0.4b34-1   (although the libz.a here is version 1.1.4, which is
                       not susceptible to this DoS)
    * sash-3.4-17     (libz.a is also version 1.1.4).
Version: GnuPG v1.2.3 (GNU/Linux)


------- Additional Comments From pekkas@netcore.fi 2004-12-15 10:07:30 ----

Hash: SHA1

Checked the SRPM and RPMs with rpm-build-compare.sh
 - original tarball integrity OK
 - spec changes minimal and OK
 - patch confirmed from OpenBSD
 - binary RPMs seem to match

I suggest someone with full FC1 tree tries to report the static issue
at/before VERIFY stage.


b6100a90dc182b7a6b9a676cb39103a6a84bc4bf  zlib-
c74105d2dfa35c895c616900089c3d3a9d80633b  zlib-
056c6e797c5b032fb8c1b58c5ff8ec39261bc871  zlib-devel-
Version: GnuPG v1.0.7 (GNU/Linux)


------- Additional Comments From deisenst@gtw.net 2004-12-16 01:09:14 ----

  Just wondering.  Were you able to build packages from the .src.rpm, using the
'rpmbuild -ba' or 'rpm -ba' commands to verify they build correctly on your
system?  Could you install the built .rpms to see if they installed okay?  I
didn't note any mention of building from the .src.rpm or installing the binary
rpms in your comment 6.

Also- your suggestion about checking a full FC1 tree is a good one.  Don't have
one myself.  If no one steps forward claiming to have one, do you or any of the
others following this bug have any suggestions how we could go about verifying
what packages would have zlib incorporated statically into any of its binaries?
 (Is there something one could do with the yum headers to find out which .rpms
even use zlib to then check those by hand or something?  I used a 'grep' command
to check binaries on my system - see comment 5).


------- Additional Comments From pekkas@netcore.fi 2004-12-16 01:49:55 ----

I did not try rebuilding or running them, because I don't even have FC1
installed.  I just verified them for correctness, so that they could be built
safely for updates-testing.  Proof that the original submitter was able to build
them should be enough :-).

Without 'install Everything tree', I could imagine two kinds of checking:
 - use of the recently published Fedora CVS to look through all the spec files
which might include questionable strings like 'zlib-devel' or 'static'.
 - doing something like 'rpm -qp --requires *.src.rpm | grep zlib-devel' on the
full src.rpm tree, if someone has one.

Neither of these is perfect, but is better than nothing.

If someone has a full tree, checking all the binaries with 'strings $foo | grep
inflate 1.2' would probably do the trick..

------- Additional Comments From rob.myers@gtri.gatech.edu 2004-12-16 05:31:55 ----

hrm we could simply test and publish the zlib from redhat's fc1 tree:


------- Additional Comments From marcdeslauriers@videotron.ca 2004-12-16 19:31:27 ----

In response to comment #8:

I have a full fc1 tree...I'll try what you suggested this weekend.

In response to comment #9:

I vote we test the packages you made earlier...bumping a version number, even if
it is from Fedora's CVS, could make testing a lot more complicated than simply
applying backported security patches...

------- Additional Comments From rob.myers@gtri.gatech.edu 2004-12-17 04:37:41 ----

re comment #10:

i agree; however i would like to see fedora legacy and redhat's fedora trees

i guess i'm more interested in how fedora-legacy can leverage redhat's "open"
cvs tree.  maybe fedora legacy members can get commit access to the legacy'd
trees?  perhaps we could shoehorn mach into redhat's build system for our
purposes?  common/Makefile.common-legacy or something?

------- Additional Comments From dom@earth.li 2004-12-17 04:39:29 ----

Re comment #10:

This would be more appropriate on the mailing list where people will see it.


------- Additional Comments From dom@earth.li 2004-12-17 04:40:04 ----


------- Additional Comments From rob.myers@gtri.gatech.edu 2004-12-17 05:13:36 ----

re comment #13:

okay, mailed.

------- Additional Comments From rob.myers@gtri.gatech.edu 2004-12-22 09:31:22 ----

Created an attachment (id=950)
script to find statically linked binaries

i used the attached script to help search for packages that had statically
linked zlib.  since the script starts with packages that require zlib-devel, it
is possible that there could be other packages that statically link zlib.

dump is statically linked (currently zlib 1.1.4)
modutils is statically linked (currently to zlib
sash is statically linked (currently to zlib 1.1.4)

cvs has zlib 1.1.4 incorporated into its source tree, but is dynamically linked
to the system's zlib.
vnc has zlib 1.1.4 incorporated into its source tree, but is dynamically linked
to the system's zlib.

Please note: This issue exists in zlib versions 1.2.0.x and 1.2.x, other
versions are not vulnerable.

it looks to me as if modutils should be rebuilt, but it is not strictly
necessary to rebuild sash and dump. 

------- Additional Comments From pekkas@netcore.fi 2004-12-22 21:08:30 ----

Thanks.  If I understood your comment correctly, sash and dump are just
statically linked, libz is not included in their sources.  If so, I suggest we
just do modutils now, to get this out of way.

------- Additional Comments From rob.myers@gtri.gatech.edu 2004-12-23 07:06:35 ----

yes, that is what i was trying to say.

------- Additional Comments From deisenst@gtw.net 2004-12-31 12:03:14 ----

Hash: SHA1

Okay.  This bug has been hanging around since September or so (though for
awhile it was closed then reopened when Red Hat didn't fix this before
Fedora Core 1 became our responsibility to maintain).

I see that this particular package has two +PUBLISH'es on Rob's packages
from comment 3.  The packages that statically-link to this library are,
in my opinion, separate issues.  And it looks like there is really only
one package, modutils, that we identify to be of concern.

I will open a separate Bugzilla issue for modutils, and may make its
completion dependent on the fixing of this bug.  Modutils really won't
need a new .src.rpm, just binaries to be recompiled that statically link
with our product here.  That also goes for any other packages we find in
the future that statically link with zlib-  There's no sense in
holding this back any further.

I vote that we PUBLISH this to updates-testing and move on with this.

Version: GnuPG v1.2.3 (GNU/Linux)


------- Additional Comments From deisenst@gtw.net 2004-12-31 12:24:21 ----

Bug 2364 (modutils) created as separate bug, depending on this bug.  Once
binaries go to updates-testing, we can publish modutils binaries to
updates-testing too.

------- Additional Comments From marcdeslauriers@videotron.ca 2005-02-09 16:18:14 ----

Packages were pushed to updates-testing.

------- Additional Comments From deisenst@gtw.net 2005-02-15 03:21:16 ----

Hash: SHA1

Verifying the Fedora Core 1 packages for zlib in updates-testing:

815ce5cc7d77184e8075d7b81f16ae94f620ffea  zlib-
e7364e589e0a06615c3a02235e54619ca58d0997  zlib-devel-
4013ab1384694342ed5083f843c2b78d1f4082a7  zlib-

  *  rpm --checksig (all are properly signed with Fedora Legacy key):
     zlib- (sha1) dsa sha1 md5 gpg OK
     zlib- (sha1) dsa sha1 md5 gpg OK
     zlib-devel- (sha1) dsa sha1 md5 gpg OK
  *  sha1sums OK
  *  rpm-build-compare.sh of these packages compare favorably with packages
     I built.
  *  Installed fine (zlib and zlib-devel).
  *  Since this is a library, post-install and post-uninstall scripts OK:
     $ rpm -q --scripts zlib
     postinstall program: /sbin/ldconfig
     postuninstall program: /sbin/ldconfig
  *  Runs fine with lynx and with the minigzip test program, and doubtless
     countless others that use zlib all the time.

VERIFY++  FC1                   -David

Version: GnuPG v1.2.3 (GNU/Linux)


------- Additional Comments From deisenst@gtw.net 2005-02-15 03:28:22 ----

Because of my heavy involvement in this bug, I would suggest we also get
another VERIFY vote from someone else.   -David

------- Additional Comments From dom@earth.li 2005-02-15 13:46:24 ----

I'm not sure another vote is necessary at this stage. What's the rationale?

------- Additional Comments From pekkas@netcore.fi 2005-02-15 19:23:04 ----

Agreed -- go for it.  If David had supplied the original package, given a
PUBLISH, or provided patches, then the situation might be different (but
necessarily wouldn't).  Now, it seems "good enough".

------- Additional Comments From deisenst@gtw.net 2005-02-16 03:50:47 ----

Ok.  Go for it.  :-)

------- Additional Comments From marcdeslauriers@videotron.ca 2005-02-23 17:57:40 ----

Packages were pushed to official updates.

------- Bug moved to this database by dkl@redhat.com 2005-03-30 18:27 -------

This bug previously known as bug 2043 at https://bugzilla.fedora.us/
Originally filed under the Fedora Legacy product and Package request component.
Bug blocks bug(s) 2364.

script to find statically linked binaries

Unknown priority P3. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Unknown severity major. Setting to default severity "normal".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Pekka Savola 2005-05-16 10:34:47 UTC
I guess these were released.

Note You need to log in before you can comment on or make changes to this bug.