This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 201335 - CVE-2006-1168 Possibility to underflow a .bss buffer with attacker controlled data
CVE-2006-1168 Possibility to underflow a .bss buffer with attacker controlled...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ncompress (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Peter Vrabec
Ben Levenson
: Security, SecurityTracking
Depends On:
Blocks: CVE-2006-1168
  Show dependency treegraph
Reported: 2006-08-04 10:02 EDT by Marcel Holtmann
Modified: 2011-08-17 13:00 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2006-0663
Doc Type: Release Note
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-12 12:47:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fix candidate (533 bytes, patch)
2006-08-10 06:03 EDT, Peter Vrabec
no flags Details | Diff

  None (edit)
Description Marcel Holtmann 2006-08-04 10:02:31 EDT
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-10 06:03:33 EDT
Created attachment 133926 [details]
fix candidate

I'd like to use this patch, which is based on fix extracted from gzip.
Comment 13 Red Hat Bugzilla 2006-09-12 12:47:29 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

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