Bug 202693 - CVE-2006-1168 Possibility to underflow a .bss buffer with attacker controlled
CVE-2006-1168 Possibility to underflow a .bss buffer with attacker controlled
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: ncompress (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Ben Levenson
impact=moderate,source=vendorsec,repo...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-15 16:43 EDT by Mark J. Cox (Product Security)
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-21 07:32:12 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 Mark J. Cox (Product Security) 2006-08-15 16:43:54 EDT
Fix needed for FC6

+++ This bug was initially created as a clone of Bug #201919 +++

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.

-- Additional comment from pvrabec@redhat.com on 2006-08-11 07:46 EST --
fixed in ncompress-4.2.4-45
Comment 1 Peter Vrabec 2006-08-21 07:32:12 EDT
rawhide fixed in ncompress-4.2.4-45
fc5 in ncompress-4.2.4-44.fc5

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