Bug 201919 (CVE-2006-1168) - CVE-2006-1168 ncompress: .bss buffer underflow in decompression
Summary: CVE-2006-1168 ncompress: .bss buffer underflow in decompression
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2006-1168
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 201335 728536 768083 772473 790335 800293 802089
Blocks: 742493 784298
TreeView+ depends on / blocked
 
Reported: 2006-08-09 19:21 UTC by Marcel Holtmann
Modified: 2023-05-12 22:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 10:06:25 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0308 0 normal SHIPPED_LIVE Low: busybox security and bug fix update 2012-02-21 07:24:58 UTC
Red Hat Product Errata RHSA-2012:0810 0 normal SHIPPED_LIVE Low: busybox security and bug fix update 2012-06-19 19:29:23 UTC

Description Marcel Holtmann 2006-08-09 19:21:31 UTC
Report from Tavis Ormandy, Google Security Team:

An audit of ncompress version 4.2.4 uncovered a serious security flaw, this loop
in decompress() (~1749, compress42.c) performs no bounds checking, allowing a
specially crafted datastream to underflow a .bss buffer with attacker controlled
data. Some research reveals that the lzw decompressors from gzip and openbsd
(both derived from the same public domain implementation) have already corrected
this flaw, however ncompress shipped by (at least) gentoo, debian, fedora and
suse seem to still be vulnerable.

              while ((cmp_code_int)code >= (cmp_code_int)256)
              { /* Generate output characters in reverse order */
                  *--stackp = tab_suffixof(code);
                  code = tab_prefixof(code);
              }

In my test environment I've been able to successfully overwirte .got and .dtors
with controlled data. The most simple testcase would be:

$ perl -e 'print "\x1f\x9d\x90","\x01"x"2048"' | compress -d

My suggested fix would be adding  `&& stackp >= htabof(0)` to the loop condition.

Comment 1 Peter Vrabec 2006-08-11 11:46:22 UTC
fixed in ncompress-4.2.4-45

Comment 3 Tomas Hoger 2011-08-17 15:45:49 UTC
This was fixed in ncompress versions shipped in Red Hat Enterprise Linux:

https://www.redhat.com/security/data/cve/CVE-2006-1168.html

and Fedora.  The fix has not bee applied to busybox yet, which include a copy of the ncompress code.

Comment 4 Tomas Hoger 2011-08-18 12:45:29 UTC
(In reply to comment #3)
> The fix has not bee applied to busybox yet, which include a copy of the
> ncompress code.

Fixed now via:
http://git.busybox.net/busybox/commit/archival/libarchive/decompress_uncompress.c?id=251fc70e9722f931eec23a34030d05ba5f747b0e

Comment 7 Murray McAllister 2012-02-03 05:49:39 UTC
Acknowledgements:

Red Hat would like to thank Tavis Ormandy of the Google Security Team for reporting this issue.

Comment 9 errata-xmlrpc 2012-02-21 03:20:48 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2012:0308 https://rhn.redhat.com/errata/RHSA-2012-0308.html

Comment 12 errata-xmlrpc 2012-06-20 07:16:07 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2012:0810 https://rhn.redhat.com/errata/RHSA-2012-0810.html


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