[19412] in bugtraq
Re: Advisory: Licq DoS +exploit
daemon@ATHENA.MIT.EDU (Stanley G. Bubrouski)
Wed Feb 28 02:16:23 2001
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.GSO.4.21.0102271725510.14579-100000@denali.ccs.neu.edu>
Date: Tue, 27 Feb 2001 17:38:10 -0500
Reply-To: "Stanley G. Bubrouski" <stan@CCS.NEU.EDU>
From: "Stanley G. Bubrouski" <stan@CCS.NEU.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
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
