Re: Advisory: Licq DoS +exploit

["Stanley G. Bubrouski" <stan () CCS NEU EDU>]

On Monday 26 February 2001 10:06, you wrote:
> > sent to a port it is listening on.  Further testing showed that
sending a
> > certain amount of data to the port the Remote Management Service (RMS)
> > plugin listens on it too would cause Licq to crash or lock up.  The
> > amount of data needed to be sent to crash Licq may vary from system to
> > system.  On the Red Hat linux 7.0 system I used 16707 or more bytes
> > sent to the port Licq was listening on was enough to crash
> > it.  Sending around 12000 or more characters to the RMS plugin port
> > was enough to crash Licq
>
> The actual problem is due to line parsing code which uses a fixed length
> (dynamically allocated) buffer of 1024 bytes.  Any string of characters
> longer then 1024 without a newline will crash the server.  This has been
> fixed in the latest CVS tree which will be released along with Licq
> 1.0.3 very soon.
>
> _____________________________________________________________________
> Graham Roff                         groff () engmail uwaterloo ca
> University of Waterloo              ICQ #2127503
> Computer Engineering                Canada
>
> Nolites tes bastardes carborundorum

After look at the CVS fix I'm noticing this problem is the result of a
buffer overflow (vsprintf) in the CLogService_Plugin::lsprintf function.
This would seem to be more serious than I originally thought if this is
indeed an exploitable overflow.  I applied this patch from CVS to a
vulnerable source tree and it fixed the problem:

diff -ur licq.1/src/log.cpp licq/src/log.cpp
--- licq.1/src/log.cpp  Mon Jun  5 20:50:03 2000
+++ licq/src/log.cpp    Sun Feb 25 15:14:16 2001
@@ -202,7 +202,8 @@
   if (m_xLogWindow == NULL) return;

   unsigned n = sprintf(szMsgMax, "%s", _szPrefix);
-  vsprintf(&szMsgMax[n], _szFormat, argp);
+  vsnprintf(&szMsgMax[n], (MAX_MSG_SIZE - n - 1), _szFormat, argp);
+  szMsgMax[MAX_MSG_SIZE - 1] = '\0';
   m_xLogWindow->AddLog(strdup(szMsgMax), _nLogType);
 }

So the seriousness of this problem could be remote execution of
code/commands as the uid Licq is running as.  I'd like to recommend anyone
using Licq as well as any Linux/Unix vendors distributing Licq to upgrade
to version 1.0.3 when it becomes available or apply the above patch
immediately.

-Stan

--
Stan Bubrouski                                       stan () ccs neu edu
316 Huntington Ave. Apt #676, Boston, MA 02115       (617) 377-7222