Bug 162392 - CAN-2005-2096 zlib buffer overflow
CAN-2005-2096 zlib buffer overflow
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: zlib (Show other bugs)
4
All Linux
medium Severity high
: ---
: ---
Assigned To: Ivana Varekova
embargo=20050706,impact=important,sou...
: Security
Depends On:
Blocks: 162680 CVE-2005-2096
  Show dependency treegraph
 
Reported: 2005-07-03 19:29 EDT by Josh Bressers
Modified: 2008-01-29 06:02 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-05 02:02:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2005-07-03 19:29:28 EDT
+++ 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 19:30:19 EDT
This issue should also affect FC3.

Please see the parent bug for all the details.
Comment 2 Josh Bressers 2005-07-06 12:24:57 EDT
Lifting embargo
Comment 3 Josh Bressers 2005-07-06 12:25:51 EDT
Can we get some FC updates for this issue soon?
Comment 4 Ivana Varekova 2005-07-07 06:14:45 EDT
There are fixed versions for devel (zlib-1.2.2.2-4), fc4 (zlib-1.2.2.2-4.fc4)
and fc3 (zlib-1.2.2.2-2.fc3). 
Comment 5 Ivana Varekova 2005-07-07 06:48:19 EDT
Oh, mistake - fc3 version is zlib-1.2.1.2-2.fc3
Comment 6 Stefan Neufeind 2005-07-21 01:59:31 EDT
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 (Product Security) 2005-07-21 05:06:45 EDT
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.

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