<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>97547</bug_id>
          
          <creation_ts>2005-06-30 14:18 0000</creation_ts>
          <short_desc>sys-libs/zlib: deflate vulnerability (CAN-2005-2096)</short_desc>
          <delta_ts>2007-08-16 18:36:08 0000</delta_ts>
          
          
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Security</product>
          <component>Vulnerabilities</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          <bug_file_loc>http://dev.gentoo.org/~taviso/files/zlib/8b318f12c58</bug_file_loc>
          <status_whiteboard>A1 [glsa]</status_whiteboard>
          
          <priority>P2</priority>
          <bug_severity>critical</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>98121</blocked>
          
          <everconfirmed>1</everconfirmed>
          <reporter>taviso@gentoo.org</reporter>
          <assigned_to>security@gentoo.org</assigned_to>
          <cc>blubb@gentoo.org</cc>
    
    <cc>corsair@gentoo.org</cc>
    
    <cc>gustavoz@gentoo.org</cc>
    
    <cc>hansmi@gentoo.org</cc>
    
    <cc>killerfox@gentoo.org</cc>
    
    <cc>kugelfang@gentoo.org</cc>
    
    <cc>tester@gentoo.org</cc>
    
    <cc>tigger@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-06-30 14:18:23 0000</bug_when>
            <thetext>I&apos;ve discovered a data stream that causes zlib to corrupt an data structure, resulting in the linked application dumping core.

Upstream contacted, but no reponse, awaiting vendor-sec to suggest alternate contact address. (note this is totally unrelated to bug 94584 )</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-06-30 14:19:47 0000</bug_when>
            <thetext>Created an attachment (id=62357)
testcase 1

sh cgi script that crashes opera/firefox by sending content-encoding: gzip.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-06-30 14:20:56 0000</bug_when>
            <thetext>Created an attachment (id=62358)
testcase 2 (png)

png file with a specially crafted IDAT chunk.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-07-01 02:39:43 0000</bug_when>
            <thetext>Created an attachment (id=62386)
testcase 1 (cgi script)

This should crash any web browser that uses zlib to handle gzip content
encoding. confirmed with dillo, firefox, opera, mozilla.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-07-01 04:09:21 0000</bug_when>
            <thetext>Created an attachment (id=62396)
testcase 3 (.gz)

specially crafted gzip file that should crash application using gzread()

$ display testcase.gz
Segmentation fault
$ clamscan testcase.gz
Segmentation fault
...etc.

$ MALLOC_CHECK_=1 identify testcase.gz 
malloc: using debugging hooks
*** glibc detected *** malloc: top chunk is corrupt: 0x08075840 ***
*** glibc detected *** free(): invalid pointer: 0x08073c78 ***
Segmentation fault

This looks like it could be exploitable to me, perhaps via sshd and corrupt
chunks of deflated data (although UsePrivilegeSeperation should stop it being
useful) or via web browser, emailed images, and so on.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-07-02 02:06:14 0000</bug_when>
            <thetext>Contacted Mark Adler, co-author of zlib who says he has forwarded my report to 
the developers mailing list for investigation.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-07-02 05:19:55 0000</bug_when>
            <thetext>Created an attachment (id=62457)
proposed patch

Mark Adler proposed the attached patch</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jaervosz@gentoo.org</who>
            <bug_when>2005-07-02 05:24:33 0000</bug_when>
            <thetext>Vapier/Solar please advise/provide an updated ebuild. </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2005-07-02 06:18:52 0000</bug_when>
            <thetext>Created an attachment (id=62463)
zlib-1.2.2-r1.ebuild
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2005-07-02 06:20:36 0000</bug_when>
            <thetext>Created an attachment (id=62464)
zlib-1.2.2-inftrees.patch

Updated patch using diff -u to go along with the updated ebuild</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2005-07-02 06:26:40 0000</bug_when>
            <thetext>Due to the nature of this and the testcases, please lets aim for getting this one 
out on or by Wend Jul 6th</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2005-07-02 07:02:06 0000</bug_when>
            <thetext>ive got local zlib ebuilds/patches ready to go ...</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2005-07-02 08:27:14 0000</bug_when>
            <thetext>Adding a selected member of releng (kugelfang) to make sure that any 
snapshots are not taken before the final release day.

kugelfang: this is still a confidential bug. 
If you could relay that fact a pretty critcial package bug is about to be fixed 
without sharing too may details to the rest of releng other than it being a core 
system package we would be thankful.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2005-07-02 08:30:33 0000</bug_when>
            <thetext>Anybody here can request CAN assignment please? (jaervosz || taviso)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kugelfang@gentoo.org</who>
            <bug_when>2005-07-02 08:38:23 0000</bug_when>
            <thetext>Just talked with plasmaroo. Resnapshotting is no problem, we&apos;re still in
prerelease phase. Thanks for letting us know!</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-07-02 08:51:48 0000</bug_when>
            <thetext>zlib author informs me CERT has been notified.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2005-07-02 13:23:13 0000</bug_when>
            <thetext>Colin Percival requested a CVE.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-07-03 00:32:23 0000</bug_when>
            <thetext>this is CAN-2005-2096</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2005-07-03 02:00:01 0000</bug_when>
            <thetext>Could be exploitable, raising rating.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jaervosz@gentoo.org</who>
            <bug_when>2005-07-03 23:29:09 0000</bug_when>
            <thetext>Arch Security liaisons, please test zlib 1.2.2-r1 and report back on this bug. 
Do NOT commit anything to Portage. </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>corsair@gentoo.org</who>
            <bug_when>2005-07-04 05:18:12 0000</bug_when>
            <thetext>I get this on ppc64:

$ display image.png
display: Corrupt image `image.png`.
$ 

I think that this correct, so ppc64 could go stable.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gustavoz@gentoo.org</who>
            <bug_when>2005-07-04 06:31:51 0000</bug_when>
            <thetext>Looks sane on sparc.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>hansmi@gentoo.org</who>
            <bug_when>2005-07-04 11:43:52 0000</bug_when>
            <thetext>Looks good on ppc. Adding KillerFox to CC for testing on hppa (I&apos;m working with
him to test it).

Other than that, why do we have to test such simple patches? Everyone who
understands a bit of C knows that this code won&apos;t break on another architecture.
So testing it on one or two would be enough. I know it&apos;s policy and such, but
that&apos;s just what I think.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>killerfox@gentoo.org</who>
            <bug_when>2005-07-04 12:28:36 0000</bug_when>
            <thetext>Looks good on hppa.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kugelfang@gentoo.org</who>
            <bug_when>2005-07-04 12:44:04 0000</bug_when>
            <thetext>Fine for amd64. gunzip didn&apos;t vomit on testcase_3.gz :-)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-07-06 07:01:39 0000</bug_when>
            <thetext>This is public at 1400UTC today.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2005-07-06 07:27:48 0000</bug_when>
            <thetext>Public followup on bug 98121
GLSA 200507-05</thetext>
          </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="0"
              isprivate="0"
          >
            <attachid>62357</attachid>
            <date>2005-06-30 14:19 0000</date>
            <desc>testcase 1</desc>
            <filename>zlib.cgi.gz</filename>
            <type>application/octet-stream</type>
            <data encoding="base64">H4sIAAAAAAACA22NsQ7CMAxE935FCTNq2oYkZUX8hZckTUsWt4IMFl/PdWFiONlnv7PPpy4W7mJ4
P5v9VbgurbpvXDPXy4PTNhdeb+36KTsxsfoxJP1C4iOJ9pD+owEaSfJMknqSKaFOJCN2FhkL7xw8
9uaKe+DNwcDPliSiH/BjAuvRZ8zcUXFTozcGDHIBzIJsgBz+ZKeaL/PNcu7WAAAA
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>62358</attachid>
            <date>2005-06-30 14:20 0000</date>
            <desc>testcase 2 (png)</desc>
            <filename>image.png</filename>
            <type>image/png</type>
            <data encoding="base64">iVBORw0KGgoAAAANSUhEUgAAAFAAAAARAQMAAABw27knAAAABlBMVEX///8AAABVwtN+AAAAG0lE
QVQoz+3BnMkwaGx3PUUSTM3WvC+YjOZ84wZEta9Va56ZAAAAAElFTkSuQmCC
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>62386</attachid>
            <date>2005-07-01 02:39 0000</date>
            <desc>testcase 1 (cgi script)</desc>
            <filename>zlib.cgi.gz</filename>
            <type>application/octet-stream</type>
            <data encoding="base64">H4sIAAAAAAACA22NsQ6DMAxEd76CpnNFgJQAa9U/6OiFQIBI1KA2g9uv77FVaoeTffY7+3jIXODM
dc852R6B45iqy8rRczxduV+HwFObTu+wEasf4vbafJtGLzGb430h/oZI8pGkdiS6hvQfFVBJ4geS
PidpetSGpMSuQqaCtxYee3PGPfBmZ+CHisShL/CjAVuj95jZveKmRm8MGOQ6MCOyHWTxx1uVfABh
ufv5+QAAAA==
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>62396</attachid>
            <date>2005-07-01 04:09 0000</date>
            <desc>testcase 3 (.gz)</desc>
            <filename>testcase.gz</filename>
            <type>application/octet-stream</type>
            <data encoding="base64">H4sIAAAAAAACA+3BnMkwaGx3PUUSTM3WvC+YjOZ84wZEta/yonHn
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>62457</attachid>
            <date>2005-07-02 05:19 0000</date>
            <desc>proposed patch</desc>
            <filename>zlib.diff</filename>
            <type>text/plain</type>
            <data encoding="base64">KioqIC4uL3psaWItMS4yLjIuMy9pbmZ0cmVlcy5jICBTdW4gRmViICA2IDIzOjQ1OjI3IDIwMDUK
LS0tIGluZnRyZWVzLmMgIFNhdCBKdWwgIDIgMTQ6MDc6NDggMjAwNQoqKioqKioqKioqKioqKioK
KioqIDEzNCwxNDAgKioqKgogICAgICAgICAgIGxlZnQgLT0gY291bnRbbGVuXTsKICAgICAgICAg
ICBpZiAobGVmdCA8IDApIHJldHVybiAtMTsgICAgICAgIC8qIG92ZXItc3Vic2NyaWJlZCAqLwog
ICAgICAgfQohICAgICBpZiAobGVmdCA+IDAgJiYgKHR5cGUgPT0gQ09ERVMgfHwgKGNvZGVzIC0g
Y291bnRbMF0gIT0gMSkpKQogICAgICAgICAgIHJldHVybiAtMTsgICAgICAgICAgICAgICAgICAg
ICAgLyogaW5jb21wbGV0ZSBzZXQgKi8KCiAgICAgICAvKiBnZW5lcmF0ZSBvZmZzZXRzIGludG8g
c3ltYm9sIHRhYmxlIGZvciBlYWNoIGxlbmd0aCBmb3Igc29ydGluZyAgKi8KLS0tIDEzNCwxNDAg
LS0tLQogICAgICAgICAgIGxlZnQgLT0gY291bnRbbGVuXTsKICAgICAgICAgICBpZiAobGVmdCA8
IDApIHJldHVybiAtMTsgICAgICAgIC8qIG92ZXItc3Vic2NyaWJlZCAqLwogICAgICAgfQohICAg
ICBpZiAobGVmdCA+IDAgJiYgKHR5cGUgPT0gQ09ERVMgfHwgbWF4ICE9IDEpKQogICAgICAgICAg
IHJldHVybiAtMTsgICAgICAgICAgICAgICAgICAgICAgLyogaW5jb21wbGV0ZSBzZXQgKi8KCiAg
ICAgICAvKiBnZW5lcmF0ZSBvZmZzZXRzIGludG8gc3ltYm9sIHRhYmxlIGZvciBlYWNoIGxlbmd0
aCBmb3Igc29ydGluZyAgKi8K
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>62463</attachid>
            <date>2005-07-02 06:18 0000</date>
            <desc>zlib-1.2.2-r1.ebuild</desc>
            <filename>zlib-1.2.2-r1.ebuild</filename>
            <type>text/plain</type>
            <data encoding="base64">IyBDb3B5cmlnaHQgMTk5OS0yMDA1IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k
ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk
ZXI6IC92YXIvY3Zzcm9vdC9nZW50b28teDg2L3N5cy1saWJzL3psaWIvemxpYi0xLjIuMi5lYnVp
bGQsdiAxLjE1IDIwMDUvMDUvMTcgMDM6NTk6MzQgdmFwaWVyIEV4cCAkCgppbmhlcml0IGV1dGls
cyBmbGFnLW8tbWF0aWMKCkRFU0NSSVBUSU9OPSJTdGFuZGFyZCAoZGUpY29tcHJlc3Npb24gbGli
cmFyeSIKSE9NRVBBR0U9Imh0dHA6Ly93d3cuZ3ppcC5vcmcvemxpYi8iClNSQ19VUkk9Imh0dHA6
Ly93d3cuZ3ppcC5vcmcvemxpYi8ke1B9LnRhci5iejIKCWh0dHA6Ly93d3cuemxpYi5uZXQvJHtQ
fS50YXIuYnoyIgoKTElDRU5TRT0iWkxJQiIKU0xPVD0iMCIKS0VZV09SRFM9ImFscGhhIGFtZDY0
IGFybSBocHBhIGlhNjQgbTY4ayBtaXBzIHBwYyBwcGM2NCBzMzkwIHNoIHNwYXJjIHg4NiIKSVVT
RT0iYnVpbGQiCgpSREVQRU5EPSIiCgpwa2dfc2V0dXAoKSB7Cgl0Yy1leHBvcnQgQ0MgUkFOTElC
CglleHBvcnQgQVI9IiQodGMtZ2V0QVIpIHJjIgp9CgpzcmNfdW5wYWNrKCkgewoJdW5wYWNrICR7
QX0KCgljZCAke1N9CgkjIE1ha2Ugc3VyZSB3ZSBsaW5rIHdpdGggZ2xpYmMgYXQgYWxsIHRpbWVz
CgllcGF0Y2ggJHtGSUxFU0RJUn0vJHtQTn0tMS4yLjEtZ2xpYmMucGF0Y2gKCSMgTmVlZGVkIGZv
ciBBbHBoYSBhbmQgcHJlbGluawoJZXBhdGNoICR7RklMRVNESVJ9LyR7UE59LTEuMi4xLWJ1aWxk
LWZQSUMucGF0Y2gKCSMgT25seSBleHBvcnQgZ2xvYmFsIHN5bWJvbHMsIGJ1ZyAjMzI3NjQKCWVw
YXRjaCAke0ZJTEVTRElSfS8ke1B9LW1hcGZpbGUucGF0Y2gKCSMgVGhlIGNvbmZpZ3VyZSBzY3Jp
cHQgY2FuIGJlIGtpbmQgb2YgZHVtYiAjNTU0MzQKCWVwYXRjaCAke0ZJTEVTRElSfS8ke1BOfS0x
LjIuMS1jb25maWd1cmUucGF0Y2gKCSMgZml4IHNoYXJlZCBsaWJyYXJ5IHRlc3Qgb24gLWZQSUMg
ZGVwZW5kYW50IGFyY2hzCgllcGF0Y2ggJHtGSUxFU0RJUn0vJHtQTn0tMS4yLjEtZlBJQy5wYXRj
aAoJIyBmaXggaW5mbGF0ZSB2dWxuIGZvdW5kIGJ5IHRhdmlzb0BnZW50b28KCWVwYXRjaCAke0ZJ
TEVTRElSfS8ke1B9LWluZnRyZWVzLnBhdGNoCn0KCnNyY19jb21waWxlKCkgewoJLi9jb25maWd1
cmUgLS1zaGFyZWQgLS1wcmVmaXg9L3VzciAtLWxpYmRpcj0vJChnZXRfbGliZGlyKSB8fCBkaWUK
CWVtYWtlIHx8IGRpZQp9CgpzcmNfaW5zdGFsbCgpIHsKCWVpbnN0YWxsIGxpYmRpcj0ke0R9LyQo
Z2V0X2xpYmRpcikgfHwgZGllCglybSAiJHtEfSIvJChnZXRfbGliZGlyKS9saWJ6LmEKCWluc2lu
dG8gL3Vzci9pbmNsdWRlCglkb2lucyB6Y29uZi5oIHpsaWIuaAoKCWlmICEgdXNlIGJ1aWxkIDsg
dGhlbgoJCWRvbWFuIHpsaWIuMwoJCWRvZG9jIEZBUSBSRUFETUUgQ2hhbmdlTG9nCgkJZG9jaW50
byB0eHQKCQlkb2RvYyBhbGdvcml0aG0udHh0CglmaQoKCSMgd2UgZG9uJ3QgbmVlZCB0aGUgc3Rh
dGljIGxpYiBpbiAvbGliCgkjIGFzIGl0J3Mgb25seSBmb3IgY29tcGlsaW5nIGFnYWluc3QKCWRv
bGliIGxpYnouYQoKCSMgYWxsIHRoZSBzaGFyZWQgbGlicyBnbyBpbnRvIC9saWIKCSMgZm9yIE5G
UyBiYXNlZCAvdXNyCglpbnRvIC8KCWRvbGliIGxpYnouc28uJHtQVn0KCSggY2QgJHtEfS8kKGdl
dF9saWJkaXIpIDsgY2htb2QgNzU1IGxpYnouc28uKiApCglkb3N5bSBsaWJ6LnNvLiR7UFZ9IC8k
KGdldF9saWJkaXIpL2xpYnouc28KCWRvc3ltIGxpYnouc28uJHtQVn0gLyQoZ2V0X2xpYmRpcikv
bGliei5zby4xCglnZW5fdXNyX2xkc2NyaXB0IGxpYnouc28KfQo=
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>62464</attachid>
            <date>2005-07-02 06:20 0000</date>
            <desc>zlib-1.2.2-inftrees.patch</desc>
            <filename>zlib-1.2.2-inftrees.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGluZnRyZWVzLmMJMjAwNS0wNy0wMiAwODo1NjoxMy4wMDAwMDAwMDAgLTA0MDAKKysrIGlu
ZnRyZWVzLmMJMjAwNS0wNy0wMiAwODo1NzoxNS4wMDAwMDAwMDAgLTA0MDAKQEAgLTEzNCw3ICsx
MzQsNyBAQAogICAgICAgICBsZWZ0IC09IGNvdW50W2xlbl07CiAgICAgICAgIGlmIChsZWZ0IDwg
MCkgcmV0dXJuIC0xOyAgICAgICAgLyogb3Zlci1zdWJzY3JpYmVkICovCiAgICAgfQotICAgIGlm
IChsZWZ0ID4gMCAmJiAodHlwZSA9PSBDT0RFUyB8fCAoY29kZXMgLSBjb3VudFswXSAhPSAxKSkp
CisgICAgaWYgKGxlZnQgPiAwICYmICh0eXBlID09IENPREVTIHx8IG1heCAhPSAxKSkKICAgICAg
ICAgcmV0dXJuIC0xOyAgICAgICAgICAgICAgICAgICAgICAvKiBpbmNvbXBsZXRlIHNldCAqLwog
CiAgICAgLyogZ2VuZXJhdGUgb2Zmc2V0cyBpbnRvIHN5bWJvbCB0YWJsZSBmb3IgZWFjaCBsZW5n
dGggZm9yIHNvcnRpbmcgKi8K
</data>        

          </attachment>
    </bug>

</bugzilla>