Bugtraq mailing list archives

[PkC] Advisory #003: micq-0.4.6 remote buffer overflow


From: recidjvo <recidjvo () pkcrew org>
Date: Thu, 18 Jan 2001 10:01:59 -0000

This is a multi-part message in MIME format.
/*                                  pkc003.txt                          */

                           -=[ SECURITY ADVISORY #003 ]=-

                 _____________                         _______
                |              \  [www.pkcrew.org]   /         \
                 \             |   ______          /     ___     \
                  |            |  |_    _|  ___   |    /     \___|
                  |            |    |  |   /  _|  |   |
                  |    _______/     |  | /  /     |   |
                  |   /             |   _ <       |   |       ___
                  |   |    [PkC]    |  |  \ \     |    \_____/   |
                 _|   |_           _|  |_   \ \_   \             |
                |_______|         |______| |____|    \__________/

                               [ Packet Knights Crew ]

                           -=[ SECURITY ADVISORY #003 ]=-



        - Vulnerable program: micq-0.4.6 (Matt's ICQ clone). Maybe others.
        - Tested on: Linux/ix86 (Slackware 7.1 - RedHat 6.1)

        - Advisory author: tHE rECIdjVO <recidjvo () pkcrew org>
        - Group: Packet Knights (http://www.pkcrew.org/)

        - Date of release: 01/18/2000

        - Problems: Remote buffer overflow
                    Local buffer overflow (not dangerous if not suid)

        - Impact: Remote vulnerablity allows to execute arbitrary code with
                the UID/GID of the user running micq.

        - Risk level: HIGH!

        - Exploit: Simple remote shell exploit for Linux/ix86 attached.

        - Dedicated to: Francesca (I'll never forget you :*)

        - Credits: The possible problem was signaled by |CyRaX| and asynchro.
                 Thanks to Nail for some crazy ideas :)

        - Greetings: Mozarela mia sinta giganta.
                     All PkC members, expecially |CyRaX| and asynchro.
                     All IRCNet friends, expecially Guybrush and IISBOSS.
                     All my Undernet bros.
                     My mom.
                     LOA guys.
                     cat ~/friends/*

        - Summary:
                micq-0.4.6 is one of the best ICQ emulator for linux console.
        There is a buffer overflow in sprintf() in icq_response.c in function
        Do_Msg() at line 879, that allows to a remote attacker able to sniff
        packets to ICQ server to execute arbitrary code on the victim system.
        There is a local buffer overflow, too.
        If you send an URL message with a too large description, the program
        receives a SIGSEGV.
        Because of the program is not suid, I don't analyze this bof further
        more.

        - Details:

        [ ... snip ... icq_response.c ... snip ... ]

void Do_Msg( SOK_T sok, DWORD type, WORD len, char * data, DWORD uin )
{
   char *tmp;
        int   x,m;
   char message[1024];
   char url_data[1024];
   char url_desc[1024];

        [ ... ]

   else if (type == URL_MESS || type == MRURL_MESS)
   {

      tmp = strchr( data, '\xFE' );
      if ( tmp == NULL )
      {
         M_print( "Ack!!!!!!!  Bad packet" );
         return;
      }
      *tmp = 0;
      char_conv ("wc",data);
      strcpy (url_desc,data);
      tmp++;
      data = tmp;
      char_conv ("wc",data);
      strcpy (url_data,data);

===>  sprintf (message,"Description: %s \n                          URL: %s",
===>            url_desc,url_data);
      if ( UIN2nick( uin ) != NULL )
         log_event( uin, LOG_MESS, "You received URL message from %s\n%s\n",
                UIN2nick(uin), message );
      else
         log_event( uin, LOG_MESS, "You received URL message from %d\n%s\n",
                uin, message );

      M_print( " URL Message.\n Description: " MESSCOL "%s" NOCOL "\n",
                url_desc );
      M_print(               " URL        : " MESSCOL "%s" NOCOL "\n",
                url_data );
   }

        [ ... snip ... icq_response.c ... snip ... ]

        The buffer overflow is due to a malicious URL message sent by the
        server. The client reads 1024 bytes from the UDP socket, trim the
        message headers and split the remaining data in the 1024 bytes
        url_data and url_desc, recombining in the message char buffer, adding
        about fifty digits. Because of the url_data is 1024 bytes long, this
        instruction can be used to overwrite the return address of the
function
        and execute arbitrary code on the client machine.

        - Solution:
        A simple patch can be to increase the message buffer size up to 50
        bytes. I've not tested if there are others problem fixin' in that way.
        I tryed to alert the micq author (Matt Smith), but homepage is out of
        order and email is unexistant.

        - Exploit:
        An exploit for Linux/ix86 is attached.
        Exploiting this bof is a little hard.
        The main problem is that we need a large amount of data to be send as
        URL, but ICQ servers seem to trim packets bigger than 500 bytes.
        So the mad way I've found is to spoof ICQ server and send the
malicious
        packet directly to the client (micq only uses server connection).
        In order to make it works, we need some extra data on the connection,
        that requires sniffing at least one packet from the existant
connection,
        like <hex_session>, that identify the connection. This can be done
        easily with tcpdump 3.6.1 (http://www.tcpdump.org/). Let's see how:

        (data and ip are random)
        [root@pkcrew:~]# tcpdump -i eth0 -s 49 -tnx udp src port 4000
        tcpdump: listening on eth0
        [ ... ]
        205.188.153.105.4000 > 32.96.111.130.1080:  udp 21 (DF)
                                 4500 0031 747f 4000 eb11 a72c cdbc 996a
                                 ceb6 3e32 0fa0 0501 001d 4c3d 0500 00f4
                                 b10f 5a
        [ ... ]
        16 packets received by filter
        0 packets dropped by kernel
        [root@pkcrew:~]#
        (<hex_session> is the last 4 shown bytes)

        Now we have all the data we need.
        Let's try to exploit this (don't try THIS ;)

        [root@pkcrew:~]# ./micRAq 32.96.111.130 1080 205.188.153.105 f4b10f4a
                [ [ micRAq ] - by tHE rECIdjVO <recidjvo () pkcrew org> ]
                        Packet Knights - http://www.pkcrew.org/

        Using buffer address: 0xbfffedb0

                "To be, or not to be.
                This is the question."
                                (William Shakespere)

        Trying 32.96.111.130...
        Connected to 32.96.111.130.
        Escape character is '^]'.
        bash$

        Good :P

        The program sends a spoofed UDP packet formatted to be parsed as an
URL
        message, but with malicious code in it. It was written using my linux
        buffer address and offset, but it can be easily changed for other
        situations.
        The shellcode open a shell on port 3879/tcp, then the exploit sends
        the execution of a inetd session with a shell binded on port
10000/tcp,
        and execl() to telnet on that port, giving you an interactive sh on
the
        remote machine.

        WARNING: when micq crashes, it prints the malicious URL, so on the
                 other side the victim see a lot of unprintable characters
                 and the /bin/sh string too.

        That's all ;)

/*                                  pkc003.txt                          */

--
tHE rECIdjVO
Member of the Packet Knights
http://www.pkcrew.org/


Attachment: micRAq.c
Description:


Current thread: