On Sun, 1 Jun 1997, Leonid S Knyshov wrote:
> As of this moment, the only good sources for ircII scripts are at
> ftp://ftp.pimpz.org and ftp://bitchx.htoc.com
Bitchx has a number of "backdoors" and is widely denigrated as a
pestilence on Unix related channels on Undernet IRC network. I haven't
dealt with the pimpz IRC script, but the spelling alone raises my hackles
as an Undernet IRC server operator/admin with long experience in dealing
with abuse scripts.
There is a set of scripts designed for Undernet use at
ftp://ftp.undernet.org/pub/irc/scripts/unix/
Speaking as an Undernet operator, my personal feeling is that the only
safe script to use on Undernet is UUS (Undernet User Script).
This script is under constant development and is heavily scrutinised for
backdoors and trojan horses. It has been ported to suit Xwindows clients
and a derivations have been available for the Mirc and Pirch clients
(Win3/Win95).
War scripts or scripts containing war components (clones, flooding,
network desynching, channel takeover components, etc) are strongly
discouraged on most IRC networks. Site admins who fail to take action
against complaints of war activities are likely to find their entire
domain and netblock barred from access to the network complaining.
IRC users are vocerious complainers, as many admins find out when this
happens. If not solved quickly, an ISP will find clients leaving for an
ISP which isn't blocked.
Additionally, most war scripts contain backdoors which allow the user to
be puppeteered (client remotely controlled, usually while suich control is
masked from the local user) or to launch non-IRC TCP/IP attacks, or to
access the local hard drive.
Windows clients in particular most commonly have these "features", but
they're known to be present in IrcII's "Phoenix" scripts.
It's perfectly possible to compromise a site's security by using a
doctored IRC script to takeover a local IRC user's machine. To make
matters worse, the "Mirc" Windows client contains a "ddeserver" which is
enabled by default and which cannot be turned off without creating a
small macro to forcibly shut it off at each sucessful server connect.
I have seen this server sucessfully used to switch on set SMB exports r/w,
allow silent transfer of files in and out of the machine and start
programs in the background. The worst part is that this can all be done
across a firewall. 'Nuff said.
AB