[9915] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Bug in IRC services

daemon@ATHENA.MIT.EDU (Andy Church)
Fri Mar 12 22:11:16 1999

Date: 	Fri, 12 Mar 1999 21:29:46 EST
Reply-To: Andy Church <achurch@DRAGONFIRE.NET>
From: Andy Church <achurch@DRAGONFIRE.NET>
X-To:         fractalg@lidernet.pt
To: BUGTRAQ@NETSPACE.ORG

     <rant> ALWAYS INFORM THE AUTHOR FIRST!  This is the first I have heard
of this alleged bug.  If you don't know the author, you can at least inform
someone that would (like IRC server administrators in this case). </rant>

     I'm looking into this now, but I haven't been able to duplicate the
scenario described by the original poster.  Services performs the following
check to determine whether a user is the "same" user as one that had
identified but disconnected (e.g. by a netsplit):

	if (ni->id_timestamp != 0 && u->signon == ni->id_timestamp)

where u->signon is the timestamp field from the NICK or USER message (or 0
if no timestamp is available), and ni->id_timestamp is set equal to
u->signon when the user identifies for their nick.  As far as I can tell,
this should be foolproof unless someone hacks one of the IRC servers to
spit out false timestamps (in which case you've got a problem on your hands
anyway).  I would appreciate any information from the original poster
demonstrating otherwise.

     I should note that the version of Services in use by irc.ptnet.org
appears to be modified; it is possible that their programmer(s) introduced
a bug such as this.  Also, as a side note, DALnet uses a Services program
of their own design, and (to the best of my knowledge) has not incorporated
any of my code.

     I will make a release tonight adding a configuration option to disable
this check and force all users to re-identify after a netsplit.  Check
http://achurch.dragonfire.net/services/ for downloading.  (The release will
also be announced on the Services mailing list; information at the above
URL.)

  --Andy Church
    achurch@dragonfire.net
    http://achurch.dragonfire.net/

>Hello,
>I've just found a big hole in services provided by IRC networks. The
>services in question are Chanserv, Nickserv, Memoserv.
>I've found them at Portuguese IRC Network aka PTNET but I think these can be
>applied to other IRC networks that are based around DALNET code since PTNET
>is a modified version of Dalnet code. If this doesn't work in other IRC
>networks at least can be a good example of very bad programming in areas
>related to security and networking.
>So let's start with a bit of background so everyone can understand what
>happened...
>As I said PTNET is based in Dalnet code and a some time ago started to
>provide 3 services to users: Chanserv ( for channels) , Nickserv ( for
>registering nicks) and Memoserv (to leave notes to other users).
>One of the problems with these services were when a netsplit occured you had
>to identify your nick when the servers rejoined so you can imagine how
>annoying it can be always having to identify the nick back every network
>split.
>So it came the new version of the servers this time with a nice feature !
>You didnt need to identify the nick when the servers rejoined from the
>split ! The first time I saw this I tought about how would the services
>recognize me as the true nick before the split... I never had the chance to
>test this theory until some days ago.
>So one server splitted and I took a nick from one administrator that wasn't
>even online ! And for my surprise when the servers rejoined I had full
>access to administrator privileges ! It just recognized the nick as a valid
>one and gave me the privileges.
>This feature as you can see is very very badly coded ( hi tourist, pantmar
>and rob_ :) ) and it's a huge security hole because anyone can just ride a
>split and take a administrator nick and then do whatever he wants ( you
>could get some user nick and what all his memos and do whatever you feel to
>his nick).
>This type of thing occurs because the server doesn't make any check, only
>checking if the nick exists in it's database. One solution of this problem
>would be keeping a database of user/ip before the split and then compare
>when servers rejoin.
>Coding something that is working on a open environment without any checks
>makes the coders being guilty in every attack the network suffers. There's
>no absolute security in a computer but these stupid things can be avoided
>and contribute to a more secure networking environment.
>I think Dalnet and other networks use the same services so if they could be
>exploitable too.
>Hoping my little contribute to be usefull to improve security around the
>world,
>Fractal Guru
>
>Any doubt feel free to email me!
>
>Greetings to : Smiler, Jaeger, Origin, Psy, Bibo, all TRPS members and the
>rest of my friends around the world!
>--
>Student at Oporto Faculty of Economy - Porto - Portugal
>Email: fractalg@lidernet.pt
>iCQ #: 17994722
>WWW soon at  http://www.dual-security.com

home help back first fref pref prev next nref lref last post