OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Stanley G. Bubrouski (stanCCS.NEU.EDU)
Date: Tue Feb 27 2001 - 16:38:10 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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 groffengmail.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                                       stanccs.neu.edu
    316 Huntington Ave. Apt #676, Boston, MA 02115       (617) 377-7222