|Summary:||CAN-2005-2096 zlib buffer overflow|
|Product:||[Fedora] Fedora||Reporter:||Josh Bressers <bressers>|
|Component:||zlib||Assignee:||Ivana Varekova <varekova>|
|Status:||CLOSED ERRATA||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-09-05 06:02:58 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Josh Bressers 2005-07-03 23:29:28 UTC
+++ This bug was initially created as a clone of Bug #162391 +++ This is text comes from Mark Adler The problem was that my previous check for an incomplete code set was much too liberal. It allowed the passage of pathological code descriptions, such as a single code of length 10, like what's in zlib-testcase.gz (twice). The deflate spec allows for distance codes with a single code, but in that case that single code must have length 1. The patch below now permits incomplete codes only if they consist of a single code of length 1. Though the spec only mentions distance codes in this regard, my patch also allows literal/length codes with a single code, which would permit a dynamic block that only defines the end-of-block code. This should be permitted by the spec, and it won't crash the code, so I'm letting it through. The consequence of letting pathological code descriptions through was that filling out the decoding table with invalid code markers overran the ENOUGH sized array and overwrote some other stuff in memory (whatever happened to follow the inflate state). I thought that I had prevented that with a check on how much of ENOUGH was being used by the literal/length code, and knowing the maximum that could possibly be used by a distance code based on an exhaustive search (MAXD). However my exhaustive search only included valid distance code sets, and so zlib-testcase.gz overran MAXD, after a similar pathological literal/length code set had used most of ENOUGH - MAXD. The patch now only allows valid code sets through, which are either exactly complete code sets or code sets that consist of a single code of length 1.
Comment 1 Josh Bressers 2005-07-03 23:30:19 UTC
This issue should also affect FC3. Please see the parent bug for all the details.
Comment 2 Josh Bressers 2005-07-06 16:24:57 UTC
Comment 3 Josh Bressers 2005-07-06 16:25:51 UTC
Can we get some FC updates for this issue soon?
Comment 4 Ivana Varekova 2005-07-07 10:14:45 UTC
There are fixed versions for devel (zlib-22.214.171.124-4), fc4 (zlib-126.96.36.199-4.fc4) and fc3 (zlib-188.8.131.52-2.fc3).
Comment 5 Ivana Varekova 2005-07-07 10:48:19 UTC
Oh, mistake - fc3 version is zlib-184.108.40.206-2.fc3
Comment 6 Stefan Neufeind 2005-07-21 05:59:31 UTC
Following the paper from Florian Weimer: http://www.enyo.de/fw/security/zlib-fingerprint/ and scanning an up to date FC4-install, it reported: - rsync - restore, modprobe, modinfo, depmod from FC4 to still contain a statically linked version against an old zlib. If somebody could confirm, would it be possible to please compile new releases?
Comment 7 Mark J. Cox 2005-07-21 09:06:45 UTC
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.