First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 66251
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Security <security@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Florian Schilhabel (RETIRED) <ruth@gentoo.org>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:
Flags: Requestee:
 
 
  ()

Filename Description Type Creator Created Size Actions
secpatch-compress.diff patch patch Florian Schilhabel (RETIRED) 2004-10-03 14:12 0000 362 bytes Details | Diff
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 66251 depends on: Show dependency tree
Show dependency graph
Bug 66251 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2004-10-03 14:11 0000
Program: compress
Homepage: ftp://ftp.leo.org/pub/comp/os/unix/linux/sunsite/utils/compress/
Vulnerable Versions: current version (4.2.4)
Risk: Low / Medium
Impact: Local Stack Buffer Overflow Vulnerability

- DESCRIPTION

 Compress is a fast, simple LZW file compressor.  Compress does not have
the highest compression rate, but it is one of the fastest programs to
compress data.  Compress is the defacto standard in the UNIX community
for compressing files.

- EXAMPLE

$ uncompress `perl -e 'print "A"x1080'`/tmp/testing
Segmentation fault (core dumped)

$ gdb --core ./core
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
Core was generated by `uncompress AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation fault.
#0  0x41414141 in ?? ()
(gdb) i r
eax            0x0      0
ecx            0x1000   4096
edx            0xf97    3991
ebx            0x41414141       1094795585
esp            0xbffff1d0       0xbffff1d0
ebp            0x41414141       0x41414141
esi            0x41414141       1094795585
edi            0x41414141       1094795585
eip            0x41414141       0x41414141
eflags         0x10282  66178
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x0      0
(gdb)

as this program is not suid per default, there is no danger of privilege escalation.
nevertheless, (un)compress is called remote by at least amavisd-new and pure-ftpd.
an attacker could remote-exploit this vulnerability by sending an carefully crafted email attachment.
amavisd-new calls uncompress, the program will overflow - as a result, attacker gains a remote shell.

attached is a patch, that fixes this problem.

best regards,
florian

------- Comment #1 From Florian Schilhabel (RETIRED) 2004-10-03 14:12:34 0000 -------
Created an attachment (id=41017) [edit]
patch

------- Comment #2 From Luke Macken (RETIRED) 2004-10-03 16:35:09 0000 -------
lv, 

This package has no metadata, and you were the last one to patch it.  Could you please verify and apply this patch?  Thanks!

------- Comment #3 From Luke Macken (RETIRED) 2004-10-03 20:25:53 0000 -------
Making this bug public since this vulnerability has already been published.

------- Comment #4 From solar 2004-10-06 20:38:34 0000 -------
+*ncompress-4.2.4-r1 (06 Oct 2004)
+
+  06 Oct 2004; <solar@gentoo.org> +metadata.xml, +ncompress-4.2.4-r1.ebuild:
+  This update adds bounds checking to command line options used by ncompress bug
+  #66251. Also minor clode cleanups and a bugfixes by using debian patch from
+  http://packages.qa.debian.org/n/ncompress.html

------- Comment #5 From Luke Macken (RETIRED) 2004-10-06 20:47:31 0000 -------
archs, please mark ncompress-4.2.4-r1 stable.

------- Comment #6 From Lars Weiler (RETIRED) 2004-10-06 22:06:56 0000 -------
Stable on ppc.  Example-test works.

------- Comment #7 From Bryan Østergaard (RETIRED) 2004-10-07 03:29:26 0000 -------
Stable on alpha.

------- Comment #8 From Ferris McCormick 2004-10-07 04:51:02 0000 -------
Stable for sparc. Runs tests for me.

------- Comment #9 From Olivier Crete 2004-10-07 05:54:25 0000 -------
stable on x86

------- Comment #10 From Jeremy Huddleston 2004-10-07 14:48:14 0000 -------
stable on amd64

------- Comment #11 From SpanKY 2004-10-07 17:48:46 0000 -------
arm/hppa/ia64/s390 stable BABY

------- Comment #12 From SpanKY 2004-10-07 18:31:33 0000 -------
mips stable

------- Comment #13 From Thierry Carrez (RETIRED) 2004-10-08 00:46:32 0000 -------
Ready for a GLSA. I would say one is needed if this is really exploitable
through amavisd[-new] or pure-ftpd (i.e. if they accept and tunnel through
uncompress arbitrary pathnames). If they don't (or if they filter
length/characters, which they should do) then a GLSA isn't needed...

------- Comment #14 From Thierry Carrez (RETIRED) 2004-10-08 11:33:12 0000 -------
This is not exploitable through pure-ftpd (which uses uncompress only in the
Makefile). Through amavisd-new, I'm not sure, but that would need to pass a
very long file name that would probably break something else.

That said, uncompress has a real potential to be called remotely in user
applications and the filename can very well be under the control of the
attacker. I would say this needs a GLSA, so my vote goes for YES

------- Comment #15 From Thierry Carrez (RETIRED) 2004-10-08 11:50:34 0000 -------
Everyone agrees, we'll do one.

------- Comment #16 From Luke Macken (RETIRED) 2004-10-09 11:44:25 0000 -------
GLSA 200410-08

ppc64, please mark stable to benefit from glsa.

------- Comment #17 From Tom Gall 2004-10-09 19:29:26 0000 -------
stable on ppc64, thanks!

------- Comment #18 From Carsten Lohrke 2005-09-26 12:15:16 0000 -------
*** Bug 107312 has been marked as a duplicate of this bug. ***

First Last Prev Next    No search results available      Search page      Enter new bug