<?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>213761</bug_id>
          <alias>CVE-2008-0888</alias>
          <creation_ts>2008-03-18 01:32 0000</creation_ts>
          <short_desc>app-arch/unzip &lt;5.52-r2 Double free vulnerability (CVE-2008-0888)</short_desc>
          <delta_ts>2008-04-06 17:20:59 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <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>
          
          <status_whiteboard>B2 [glsa]</status_whiteboard>
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>rbu@gentoo.org</reporter>
          <assigned_to>security@gentoo.org</assigned_to>
          <cc>arm@gentoo.org</cc>
    
    <cc>hanno@gentoo.org</cc>
    
    <cc>m68k@gentoo.org</cc>
    
    <cc>s390@gentoo.org</cc>
    
    <cc>sh@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>rbu@gentoo.org</who>
            <bug_when>2008-03-18 01:32:50 0000</bug_when>
            <thetext>Tavis Ormandy writes:

the inflate_dynamic() routine (~978, inflate.c) uses a macro
NEEDBITS() that jumps execution to a cleanup routine on error, this
routine attempts to free() two buffers allocated during the inflate
process. At certain locations, the NEEDBITS() macro is used while the
pointers are not pointing to valid buffers, they are either
uninitialised or pointing inside a block that has already been free()d
(ie, not pointing at the block, but at a location inside it).

In both cases, the possibility of controlling either the pointer (eg,
by altering the unitialized data on the stack left over from some
previous subroutine call), or the buffer pointed at by the pointer, is
small but perhaps non-zero.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>rbu@gentoo.org</who>
            <bug_when>2008-03-18 01:34:02 0000</bug_when>
            <thetext>base-system, please find the patch attached. No upstream bump to be expected, smithj tried contacting them without success.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>rbu@gentoo.org</who>
            <bug_when>2008-03-18 01:34:49 0000</bug_when>
            <thetext>Created an attachment (id=146443)
unzip-5.5.2-CVE-2008-0888.patch

Courtesy of Tavis</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>smithj@gentoo.org</who>
            <bug_when>2008-03-18 04:44:31 0000</bug_when>
            <thetext>(In reply to comment #1)
&gt; smithj tried contacting them without success.

Yeah. Actually, if anyone has a contact for them, please pass this info along!

</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2008-03-18 11:28:10 0000</bug_when>
            <thetext>i&apos;d drop the last two hunks of that patch as one is simply whitespace change and the other is redundant -- huft_free() already performs the if(NULL) test</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>rbu@gentoo.org</who>
            <bug_when>2008-03-18 12:16:54 0000</bug_when>
            <thetext>(In reply to comment #4)
&gt; i&apos;d drop the last two hunks of that patch as one is simply whitespace change
&gt; and the other is redundant -- huft_free() already performs the if(NULL) test

sounds good, taviso complained about losing performance though ;-)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>rbu@gentoo.org</who>
            <bug_when>2008-03-27 21:13:08 0000</bug_when>
            <thetext>spanky, any updates here?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2008-03-29 02:37:54 0000</bug_when>
            <thetext>added unzip-5.5.2-r2 to the tree w/the patch ... not that i really looked into the issue to verify correctness of the patch</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>rbu@gentoo.org</who>
            <bug_when>2008-03-29 10:04:45 0000</bug_when>
            <thetext>(In reply to comment #7)
&gt; added unzip-5.5.2-r2 to the tree w/the patch ... not that i really looked into
&gt; the issue to verify correctness of the patch

Couldn&apos;t reproduce the error with taviso&apos;s PoC.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>rbu@gentoo.org</who>
            <bug_when>2008-03-29 10:05:17 0000</bug_when>
            <thetext>Arches, please test and mark stable:
=app-arch/unzip-5.52-r2
Target keywords : &quot;alpha amd64 arm hppa ia64 m68k ppc ppc64 release s390 sh sparc x86&quot;
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>rbu@gentoo.org</who>
            <bug_when>2008-03-29 10:12:43 0000</bug_when>
            <thetext>amd64 stable</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>fauli@gentoo.org</who>
            <bug_when>2008-03-29 11:15:45 0000</bug_when>
            <thetext>x86 stable</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>ranger@gentoo.org</who>
            <bug_when>2008-03-29 15:33:03 0000</bug_when>
            <thetext>ppc and ppc64 done</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>armin76@gentoo.org</who>
            <bug_when>2008-03-29 16:06:31 0000</bug_when>
            <thetext>alpha/ia64/sparc stable</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jer@gentoo.org</who>
            <bug_when>2008-03-29 16:57:02 0000</bug_when>
            <thetext>Stable for HPPA.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>pva@gentoo.org</who>
            <bug_when>2008-03-30 11:41:42 0000</bug_when>
            <thetext>Fixed in release snapshot.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>rbu@gentoo.org</who>
            <bug_when>2008-04-06 17:20:59 0000</bug_when>
            <thetext>GLSA 200804-06.</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>146443</attachid>
            <date>2008-03-18 01:34 0000</date>
            <desc>unzip-5.5.2-CVE-2008-0888.patch</desc>
            <filename>unzip-5.5.2-CVE-2008-0888.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGluZmxhdGUuYwkyMDA1LTAyLTI3IDA2OjA4OjQ2LjAwMDAwMDAwMCArMDAwMAorKysgaW5m
bGF0ZS5jCTIwMDYtMDctMTkgMjE6NDU6MzMuNTQzNTk1MDAwICswMTAwCkBAIC05ODMsNiArOTgz
LDcgQEAKICAgdW5zaWduZWQgbDsgICAgICAgICAgIC8qIGxhc3QgbGVuZ3RoICovCiAgIHVuc2ln
bmVkIG07ICAgICAgICAgICAvKiBtYXNrIGZvciBiaXQgbGVuZ3RocyB0YWJsZSAqLwogICB1bnNp
Z25lZCBuOyAgICAgICAgICAgLyogbnVtYmVyIG9mIGxlbmd0aHMgdG8gZ2V0ICovCisgIHN0cnVj
dCBodWZ0ICp0bHA7ICAgICAKICAgc3RydWN0IGh1ZnQgKnRsOyAgICAgIC8qIGxpdGVyYWwvbGVu
Z3RoIGNvZGUgdGFibGUgKi8KICAgc3RydWN0IGh1ZnQgKnRkOyAgICAgIC8qIGRpc3RhbmNlIGNv
ZGUgdGFibGUgKi8KICAgdW5zaWduZWQgYmw7ICAgICAgICAgIC8qIGxvb2t1cCBiaXRzIGZvciB0
bCAqLwpAQCAtOTk2LDYgKzk5Nyw4IEBACiAgIGludCByZXR2YWwgPSAwOyAgICAgICAvKiBlcnJv
ciBjb2RlIHJldHVybmVkOiBpbml0aWFsaXplZCB0byAibm8gZXJyb3IiICovCiAKIAorICB0ZCA9
IHRscCA9IHRsID0gKHN0cnVjdCBodWZ0ICopTlVMTDsKKwogICAvKiBtYWtlIGxvY2FsIGJpdCBi
dWZmZXIgKi8KICAgVHJhY2UoKHN0ZGVyciwgIlxuZHluYW1pYyBibG9jayIpKTsKICAgYiA9IEcu
YmI7CkBAIC0xMDQ3LDkgKzEwNTAsOSBAQAogICB3aGlsZSAoaSA8IG4pCiAgIHsKICAgICBORUVE
QklUUyhibCkKLSAgICBqID0gKHRkID0gdGwgKyAoKHVuc2lnbmVkKWIgJiBtKSktPmI7CisgICAg
aiA9ICh0bHAgPSB0bCArICgodW5zaWduZWQpYiAmIG0pKS0+YjsKICAgICBEVU1QQklUUyhqKQot
ICAgIGogPSB0ZC0+di5uOworICAgIGogPSB0bHAtPnYubjsKICAgICBpZiAoaiA8IDE2KSAgICAg
ICAgICAgICAgICAgLyogbGVuZ3RoIG9mIGNvZGUgaW4gYml0cyAoMC4uMTUpICovCiAgICAgICBs
bFtpKytdID0gbCA9IGo7ICAgICAgICAgIC8qIHNhdmUgbGFzdCBsZW5ndGggaW4gbCAqLwogICAg
IGVsc2UgaWYgKGogPT0gMTYpICAgICAgICAgICAvKiByZXBlYXQgbGFzdCBsZW5ndGggMyB0byA2
IHRpbWVzICovCkBAIC0xMTQxLDYgKzExNDQsNyBAQAogICAgICAgaHVmdF9mcmVlKHRkKTsKICAg
ICB9CiAgICAgaHVmdF9mcmVlKHRsKTsKKwogICAgIHJldHVybiByZXR2YWw7CiAgIH0KIApAQCAt
MTE0OSw4ICsxMTUzLDggQEAKIAogY2xlYW51cF9hbmRfZXhpdDoKICAgLyogZnJlZSB0aGUgZGVj
b2RpbmcgdGFibGVzLCByZXR1cm4gKi8KLSAgaHVmdF9mcmVlKHRsKTsKLSAgaHVmdF9mcmVlKHRk
KTsKKyAgaWYgKHRsKSBodWZ0X2ZyZWUodGwpOworICBpZiAodGQpIGh1ZnRfZnJlZSh0ZCk7CiAg
IHJldHVybiByZXR2YWw7CiB9CiAK
</data>        

          </attachment>
    </bug>

</bugzilla>