Several posts have been made concerning the libc bug being exploited
through ircII clients. This is what I have been able to figure out
so far:

The bug is *not* in the irc clients, but in libc's atoi() function,
which lacks the correct bounds checking. As far as I know, this bug
is present in all libc versions after 5.0.0, and was finally fixed
in version 5.3.12.

The exploit script that has been circulated, screw.irc, was *never*
able to provide a shell through the client as far as I can tell.
I studied the code, and except for some initial pointers, it turns
out to be exactly the same as what was used in egg.c, the exploit
for the splitvt bug that most of you will remember. Someone probably
put it in there to see if this caused the same kind of vulnerability.

*NOTE* None of this code has to be present to be able to crash the
client! In fact, it is sufficient to send a DCC send or chat command
with a second argument long enough to overflow atio()'s buffer. The
limit appears to be 199 characters -- everything above that will
cause a segmentation fault and exit the client. Thus,
   /ctcp <nick> dcc send duh <200 0's> 0
and
   /ctcp <nick> dcc chat chat <200 0's> 0
will both crash the client.

The second argument is only supposed to consist of no more than 10
digits, so writing a script to prevent this hack is simple:

/on ^raw_irc "% PRIVMSG % *DCC % % ???????????* *" {
   echo Possible libc bug exploit received in DCC $4 from $0
}

This will prevent DCC requests with a second argument of 11 characters
or more from being processed by ircII, and should do the trick if you
happen to be too lazy to update libc.


.../zarq

Runar Jensen  [zarquon@popalex1.linknet.net]