http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0797 Vulnerable: <=zlib-1.2.1 Patch at: ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.5/common/017_libz.patch ------- Additional Comments From marcdeslauriers 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. Ref: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131385 http://www.suse.com/de/security/2004_29_zlib.html ------- Additional Comments From fedora-legacy-bugzilla-2004 2004-11-09 17:52:41 ---- Fedora Core 1 is affected of this issue. ------- Additional Comments From rob.myers.edu 2004-11-19 08:50:50 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is an updated zlib packages to QA for fc1: - - should fix CAN-2004-0797 - - uses the patch, available from 2 places: ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.5/common/017_libz.patch https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=103317&action=view - - are there other programs that have incorporated vulnerable zlib code? changelog: * Fri Nov 19 2004 Rob Myers <rob.myers.edu> 1.2.0.7-2.1.legacy - - apply patch for CAN-2004-0797 (FL #2043) sha1sums: c74105d2dfa35c895c616900089c3d3a9d80633b zlib-1.2.0.7-2.1.legacy.i386.rpm b6100a90dc182b7a6b9a676cb39103a6a84bc4bf zlib-1.2.0.7-2.1.legacy.src.rpm 01e2da015548e73e4f7d131943d943030f2e5fa3 zlib-debuginfo-1.2.0.7-2.1.legacy.i386.rpm 056c6e797c5b032fb8c1b58c5ff8ec39261bc871 zlib-devel-1.2.0.7-2.1.legacy.i386.rpm files: http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/zlib-1.2.0.7-2.1.legacy.src.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/zlib-1.2.0.7-2.1.legacy.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/zlib-debuginfo-1.2.0.7-2.1.legacy.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/zlib-devel-1.2.0.7-2.1.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBnkAKtU2XAt1OWnsRAiNaAKDkMlZDKkgPEuBYTFOgdVQlYqKWwQCbB0dz RDnjspWBT5u1Li28XGKYIfc= =5xvZ -----END PGP SIGNATURE----- ------- Additional Comments From deisenst 2004-11-24 09:40:22 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did QA on Rob's zlib FC1 package. b6100a90dc182b7a6b9a676cb39103a6a84bc4bf zlib-1.2.0.7-2.1.legacy.src.rpm * sha1sum ok * PGP signature on Rob's key okay * source file okay (compared to zlib-1.2.0.7-2) * spec file looks great * patch for CAN-2004-0797 looks good; comparable to patch in RH Bugzilla #131385 * 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBpOMmxou1V/j9XZwRAif8AJ4o+TduLLRYCxrxI4cCjNUbvc6lEQCgr0DS 3Yo/r5n9cEVD+ThNb6MMaGY= =Svei -----END PGP SIGNATURE----- ------- Additional Comments From deisenst 2004-11-24 09:47:01 ---- -----BEGIN PGP SIGNED MESSAGE----- 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 1.2.0.7 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). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBpOUgxou1V/j9XZwRAsmuAKCKwwJM340QzKWWjoE3J03wcRDhFQCfSXK6 NpGIY2NHaGFCzg55/Y9lSao= =ywAH -----END PGP SIGNATURE----- ------- Additional Comments From pekkas 2004-12-15 10:07:30 ---- -----BEGIN PGP SIGNED MESSAGE----- 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. +PUBLISH b6100a90dc182b7a6b9a676cb39103a6a84bc4bf zlib-1.2.0.7-2.1.legacy.src.rpm c74105d2dfa35c895c616900089c3d3a9d80633b zlib-1.2.0.7-2.1.legacy.i386.rpm 056c6e797c5b032fb8c1b58c5ff8ec39261bc871 zlib-devel-1.2.0.7-2.1.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFBwJlHGHbTkzxSL7QRAulJAJ4xQ9zXaYWIAoqNjEotteD1pH+TiQCePMly sH1AsVagrwrq/Z4qtCNKifo= =e4aM -----END PGP SIGNATURE----- ------- Additional Comments From deisenst 2004-12-16 01:09:14 ---- Pekka, 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). -David ------- Additional Comments From pekkas 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.edu 2004-12-16 05:31:55 ---- hrm we could simply test and publish the zlib from redhat's fc1 tree: http://cvs.fedora.redhat.com/viewcvs/rpms/zlib/FC-1/zlib.spec?rev=1.11&view=markup comments? ------- Additional Comments From marcdeslauriers 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.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 converge. 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 2004-12-17 04:39:29 ---- Re comment #10: This would be more appropriate on the mailing list where people will see it. Cheers, ------- Additional Comments From dom 2004-12-17 04:40:04 ---- s/10/11/ ------- Additional Comments From rob.myers.edu 2004-12-17 05:13:36 ---- re comment #13: okay, mailed. https://www.redhat.com/archives/fedora-legacy-list/2004-December/msg00104.html ------- Additional Comments From rob.myers.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 1.2.0.7) 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 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.edu 2004-12-23 07:06:35 ---- yes, that is what i was trying to say. ------- Additional Comments From deisenst 2004-12-31 12:03:14 ---- -----BEGIN PGP SIGNED MESSAGE----- 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-1.2.0.7. There's no sense in holding this back any further. I vote that we PUBLISH this to updates-testing and move on with this. PUBLISH+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFB1czkxou1V/j9XZwRAtb0AKCecVN0UsM2+509n/J3zxTFstUDOQCeJqJp lxLqKas/L0l0i1pE1T+GZ+E= =DKo7 -----END PGP SIGNATURE----- ------- Additional Comments From deisenst 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 2005-02-09 16:18:14 ---- Packages were pushed to updates-testing. ------- Additional Comments From deisenst 2005-02-15 03:21:16 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Verifying the Fedora Core 1 packages for zlib in updates-testing: 815ce5cc7d77184e8075d7b81f16ae94f620ffea zlib-1.2.0.7-2.1.legacy.i386.rpm e7364e589e0a06615c3a02235e54619ca58d0997 zlib-devel-1.2.0.7-2.1.legacy.i386.rpm 4013ab1384694342ed5083f843c2b78d1f4082a7 zlib-1.2.0.7-2.1.legacy.src.rpm * rpm --checksig (all are properly signed with Fedora Legacy key): zlib-1.2.0.7-2.1.legacy.i386.rpm: (sha1) dsa sha1 md5 gpg OK zlib-1.2.0.7-2.1.legacy.src.rpm: (sha1) dsa sha1 md5 gpg OK zlib-devel-1.2.0.7-2.1.legacy.i386.rpm: (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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCEfZxxou1V/j9XZwRAi+xAKDH3CwsuKQEpQYZDGGU3zO382BcbACgmjxC Jp9MF3YN7B9Iv8xl8W9Trlo= =jcTX -----END PGP SIGNATURE----- ------- Additional Comments From deisenst 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 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 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 2005-02-16 03:50:47 ---- Ok. Go for it. :-) ------- Additional Comments From marcdeslauriers 2005-02-23 17:57:40 ---- Packages were pushed to official updates. ------- Bug moved to this database by dkl 2005-03-30 18:27 ------- This bug previously known as bug 2043 at https://bugzilla.fedora.us/ https://bugzilla.fedora.us/show_bug.cgi?id=2043 Originally filed under the Fedora Legacy product and Package request component. Bug blocks bug(s) 2364. Attachments: script to find statically linked binaries https://bugzilla.fedora.us/attachment.cgi?action=view&id=950 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.
I guess these were released.