COMMAND

    ircii-pana (BitchX)

SYSTEMS AFFECTED

    Linux

PROBLEM

    Michal Zalewski found interesting overflow in dgets(...)  function
    in one of the most popular irc clients, BitchX 74p4 (by panasync).
    You can cause  remote client crash  (and possibly much  more) when
    you're  fingered  (/finger  built-in  command)  by victim - simply
    create  eg.   .plan  with  line  longer  than 2 kbytes.  Depending
    on used line (ln /dev/urandom ~/.plan is nice), client will  crash
    with SEGV immediately or during any next '/' command...

    With about 3000 'A' letters followed by original .plan, you get:

        Program received signal SIGSEGV, Segmentation fault.
        0x41414141 in ?? ()

    Almost anyone is able to modify less or more generic shellcode.

SOLUTION

    This problem has been fixed in the 75 alpha versions. If you would
    like, you can obtain a 75aX binary through one of two methods:

        1. /ctcp q cdcc list - on efnet
           (user@host <->q!panasync@colossus.melnibone.org)
        2. ftp://brian.got.net/pub/BitchX

    glibc and libc5 bins are available. Please keep in mind these  are
    test versions  and are  not stable.   As for  quick fix,  at least
    sufficient in above situation:

    --- newio.c.orig        Tue Nov 18 04:49:28 1997
    +++ newio.c     Mon May 25 13:25:58 1998
    @@ -296,7 +296,7 @@
            {
                    if (((str[cnt] = ioe->buffer[ioe->read_pos++])) == '\n')
                            break;
    -               cnt++;
    +               if (++cnt>=BIG_BUFFER_SIZE) ioe->read_pos=ioe->write_pos;
            }

            /*

    Richard Braakman posted complete patch as the real problem is that
    dgets()  has  no  way  to  know  its  callers  buffer size.  It is
    sometimes called with buffers  that are considerably smaller  than
    BIG_BUFFER_SIZE, and in one case with a buffer whose size can vary
    at run time.  The proper patch is to give dgets another  parameter
    to specify the caller's buffer  size.  Fortunately there are  only
    about a  dozen calls  to it.   You can  find his  patch at BugTraq
    archives.