Stack-based buffer overflow in the comprexx function for ncompress 4.2.4 and earlier, when used in situations that cross security boundaries (such as FTP server), may allow remote attackers to execute arbitrary code via a long filename argument.

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 ((cmpcodeint)code >= (cmpcodeint)256) { / Generate output characters in reverse order / --stackp = tabsuffixof(code); code = tabprefixof(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.

BSD compress implemented an LZW compressor and decompressor. This decompressor implementation did not correctly handle compressed streams that contain code words that were not yet added to the decompression table. LZW decompression has a special case (a KwKwK string) when code word may match the first free entry in the decompression table. The implementation used in BSD compress allow code words not only matching, but also exceeding the first free entry.

It seems this compress implementation first appeared in BSD around 1985, and was later used in various other code base, such as ncompress and gzip. Other components that contain affected code will be listed below. Following page list the version of the code as was used in 4.3BSD:

http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/compress/compress.c

Relevant code appears in the decompress() routine:

/ Special case for KwKwK string. / if ( code >= freeent ) { stackp++ = finchar; code = oldcode; }

This allows creating a loop in the decompression table, which leads to an "infinite" loop:

/ Generate output characters in reverse order / #ifdef SIGNEDCOMPARESLOW while ( ((unsigned long)code) >= ((unsigned long)256) ) { #else while ( code >= 256 ) { #endif stackp++ = tabsuffixof(code); code = tabprefixof(code); }

where tabprefixof is:

unsigned short codetab [HSIZE]; #define codetabof(i) codetab[i] #define tabprefixof(i) codetabof(i)

This overflows destack "buffer" (part of the htab[]):

countint htab [HSIZE]; # define tabsuffixof(i) ((chartype )(htab))[i] # define destack ((chartype )&tabsuffixof(1<<BITS))

Depending on the relative htab[] and codetab[] positions, destack overflow may overwrite codetab[] entries, which may break infinite loop and let program continue its execution with possibly corrupted memory.

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 ((cmpcodeint)code >= (cmpcodeint)256) { / Generate output characters in reverse order / --stackp = tabsuffixof(code); code = tabprefixof(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.

ncompress 4.2.4 and earlier allows local users to overwrite arbitrary files via a symlink attack on temporary files using (1) zdiff or (2) zcmp, a different vulnerability than CVE-2004-0970.