+++ This bug was initially created as a clone of Bug #162392 +++ +++ This bug was initially created as a clone of Bug #162391 +++ This affects zlib 1.2 and up, which is FC1 and FC2. See: http://rhn.redhat.com/errata/RHSA-2005-569.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Created SRPMs using patch from FC4 package: FC1: http://www.cs.ucsb.edu/~jeff/legacy/zlib-1.2.0.7-2.2.legacy.src.rpm FC2: http://www.cs.ucsb.edu/~jeff/legacy/zlib-1.2.1.2-1.fc2.legacy.src.rpm Checksums: 4c8f526dbed8d61a82ccf8af189023e19b5f723e zlib-1.2.0.7-2.2.legacy.src.rpm 322ef60e9d141c5532b70cd4734e77e4693a434a zlib-1.2.1.2-1.fc2.legacy.src.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC1YXIKe7MLJjUbNMRAmsNAKCyga65/AoqSTopQcUuTFMMpwishQCgueRw 595TRpX1diQgZXGZy3SPBcg= =RYWO -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA w/ rpm-build-compare.sh: - source integrity OK - spec file changes minimal - patches verified to match RHEL4 +PUBLISH FC1, FC2 4c8f526dbed8d61a82ccf8af189023e19b5f723e zlib-1.2.0.7-2.2.legacy.src.rpm 322ef60e9d141c5532b70cd4734e77e4693a434a zlib-1.2.1.2-1.fc2.legacy.src.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFC1i48GHbTkzxSL7QRAlWJAJ9GW/S2KZQkGTnTYt3tdYRcEb1bbACeLkCs 3bfextltat/Jt/VzEzH6u98= =6rMh -----END PGP SIGNATURE-----
Packages were pushed to updates-testing
Following the paper from Florian Weimer: http://www.enyo.de/fw/security/zlib-fingerprint/ and scanning an up to date FC3-install, it reported: - rsync 2.6.3-1 - restore, modprobe, modinfo, depmod from FC3 to still contain a statically linked version against an old zlib. If somebody could confirm, would it be possible to please compile new releases?
modprobe, modinfo, depmod have no security context (if you have a malcious kernel module you're about to load it doesn't really matter if it can exploit you by zlib). restore/dump similarly. rsync includes version 1.1.4 of zlib and is therefore unaffected by this issue.
05.28.26 CVE: CAN-2005-2096 Platform: Cross Platform Title: Zlib Compression Library Buffer Overflow Vulnerability Description: The Zlib compression library is a library designed for compression and decompression of data. It is reported to be vulnerable to a buffer overflow issue in the "inflate_table()" function in the "inftrees.c" file. Zlib versions 1.2.2 and earlier are reported to be vulnerable. Ref: http://www.securityfocus.com/bid/14162 (6) HIGH: zlib Compression Library Buffer Overflow Affected: zlib version 1.2.1 and 1.2.2 Description: zlib is a popular compression library that is widely used by programs across all OSs including Linux, Mac OS and Windows. This library contains a buffer overflow that can be triggered by a specially crafted compressed file. An attacker, who can deliver such a crafted file to a program using zlib, may exploit the overflow to execute arbitrary code. For example, a webserver can set "Content-Encoding" HTTP header to gzip, which may lead to an overflow in the browser using the zlib library. The technical details required to craft a malicious file may be obtained by examining the patch. Status: The vendor will release an official update soon. Many Linux vendors have already provided updates. A list of applications that use zlib can be found at: http://www.gzip.org/zlib/apps.gz.html. Many of these applications may require an update from the corresponding vendor. Council Site Actions: Only a few of the council sites are responding to this item. One site said their Linux systems will obtain updated packages from the Linux vendor, as the packages become available. Another site will patch their externally accessible servers immediately, and then roll out to internal servers as part of their standard patch cycle. The other sites are still evaluating their risk/exposure level and formulating a remediation response. References: Gentoo Advisory (Gentoo researcher reported the bug) http://www.gentoo.org/security/en/glsa/glsa-200507-05.xml Handler's Diary Posting http://isc.sans.org/diary.php?date=2005-07-10 Ways to Identify Programs With Statically Linked zlib http://www.enyo.de/fw/security/zlib-fingerprint/ Vendor Homepage http://www.zlib.net/ SecurityFocus BID http://www.securityfocus.com/bid/14162
The issue(s) listed in the previous comment (#6) appear to be the ones already handled by this update, unless I'm mistaken.
Works for me. +VERIFY FC1.
Any other verifies? I'll mark Gilbert's verified, even though unsigned, but won't start a timeout at least yet..
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Verify for FC2 packages: 7ec6202d58ed3a41f3575757b111ab88622081d7 zlib-1.2.1.2-0.fc2.1.legacy.i386.rpm 450f8ce4f02f36dbee569c0a9fdbe772829dce15 zlib-devel-1.2.1.2-0.fc2.1.legacy.i386.rpm Signatures OK Packages install OK Packages linked to libz still work as expected FC2 VERIFY++ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC9FBSKe7MLJjUbNMRAozjAKCF/DCJrPwWyN207NvEPDIU6Sv2qACeNLG8 DvON4Mr8u9sX4hXu/eMiHsw= =ueQ8 -----END PGP SIGNATURE-----
Thanks!
Looks like we forgot CAN-2005-1849. Since the patch to fix it was trivial, I rebuilt packages with it included and put them directly into testing. Please test and as soon as we get 1 VERIFY, I'll release them.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Verifying the Fedora Core 1 packages for zlib in updates-testing: f242225e07d39648b0d7d6558150285ddf7f62d8 zlib-1.2.0.7-2.3.legacy.i386.rpm 618d744e5a8f9a895b40f952a8593985c93fd6d6 zlib-devel-1.2.0.7-2.3.legacy.i386 .rpm c812abcd0c5bcfccc86573e81d68ebff5b615ded zlib-1.2.0.7-2.3.legacy.src.rpm .src.rpm: ========= * Comparing it with a previous .src.rpm: Looks good -- * specfile changes minimal * patch files look good - very small changes. * PUBLISH++ .i386.rpms: =========== * rpm --checksig (all are properly signed with Fedora Legacy key): zlib-1.2.0.7-2.3.legacy.i386.rpm: (sha1) dsa sha1 md5 gpg OK zlib-devel-1.2.0.7-2.3.legacy.i386.rpm: (sha1) dsa sha1 md5 gpg OK zlib-1.2.0.7-2.3.legacy.src.rpm: (sha1) dsa sha1 md5 gpg OK * rpm-build-compare.sh of these packages compare favorably with previous zlib packages * Installed fine (zlib and zlib-devel). * Since this is a library, post-install and post-uninstall scripts OK: $ rpm -qp --scripts zlib-1.2.0.7-2.3.legacy.i386.rpm postinstall program: /sbin/ldconfig postuninstall program: /sbin/ldconfig * Currently, over 41 processes on my system are linking to this installed libz.so.1 (including the gedit window I'm typing in): nary a burp. * Runs fine, tastes great!! VERIFY++ FC1 -David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFDBnyexou1V/j9XZwRAo5gAJ9ldzbB/qYLg2/C7debTRw7E3g7kgCfQ/ZN 9iMdfBAWUqEtAkd4zI2+x+4= =2sRp -----END PGP SIGNATURE-----
Question: How do we test zlib to ensure the DoS conditions (CAN-2005-2096 & CAN-2005-1849) are fixed before we release packages to updates and issue an Errata? I've dug and dug and cannot find any example files to use TO test that the DoS conditions in zlib have been fixed. It bothers me that we cannot test this. The Fedora Core 3 fix for this apparently is in Bug #163038. From Fedora Update Notification FEDORA-2005-625 at <http://tinyurl.com/77c88>: * Fri Jul 22 2005 Ivana Varekova <varekova redhat com> 1.2.1.2-3.fc3 - fix bug 163038 - CAN-2005-1849 - zlib overflow problem Bug #163038 may include information on how to test the fixed zlibs. But I cannot open that Bug. Can anyone else?
I can't access it either, probably something embargoed by redhat.
opened bug, but nothing useful in it. (Feel free to mail secalert if you see bugs that you think you should be able to access but can't -- we usually catch these ourselves but in this case the embargo was lifted early and we updated the el bug but not the fc version).
Well, I'd say go ahead and release this. Zlib has been working great on my machine for a few days now. It may be bothersome not to be able to find any tests for the vulnerabilities, but that's just the way it is. -David
*** Bug 167298 has been marked as a duplicate of this bug. ***
Packages were released.