Re: Anti-collide patch

[Matthew Sullivan <mickey@xxxxxxxxxxxxxxx>]

Michal *pht* Svoboda wrote:
> 
> On Sun, 10 Jan 1999, Matthew Sullivan wrote:
> 
> > Michal *pht* Svoboda wrote:
> > >
> > > On Sun, 10 Jan 1999, Joern Westermann wrote:
> > >
> > > > Kaspar Landsberg wrote:
> > > > >
> > > > > the problem with the FNC (forced nick change) solution is that it can easily
> > > > > result in a loop. Suppose a nick collision happens and Guenthi changes to
> > > > > Guent6387. But now, there´s some guy sitting on one of your channels and
> > > > > sees that you get a new nick. All he needs now is a lagged server or a
> > > > > server which is currently reconnecting and he can hook up "on the other
> > > > > side" a client with the same nick, resulting in a nick collision, which
> > > > > makes the whole thing restart from 0 ad infinitum.
> > > >
> > > > I know. This way a channel cannot be taken over, but it'll be a totally
> > > > useless channel. But I could also think about a script to defend against
> > > > this approach: It notices a collide and after the channel rejoin it
> > > > kicks out all non-channel ops and sets the channel +i. So it's
> > > > impossible for the attacker to find out the new nick after the next
> > > > collide.
> > > > Ok, I also hate those warscripts. :(
> > > this wouldnt be any use because the attacker sits on lagged server, which
> > > doesnt get the kick.
> >
> > Ah but it would, cause the lagged server won't get the new nick until
> > the kick has already got there....
> >
> > However I see your point, multiple clients would solve it if they all
> > notice the collide and clear the chan, rather than changing nicks (as in
> > the usual lame anticollide scripts) it will sort it...  If the oper is
> > the last op in channel it'll have a problem.
> >
> > The other think is to send a new code out to the server _BEFORE_ the
> > change takes place locally, which locks the new nick before the change
> > happens (and kills anything with it/forces it's nick to change..), the
> > only problem in this approach is that you'll probably get one or two
> > innocent lusers.  But that could of course happen with a FNC in the
> > first place anyhow....
> >
> > ...and we go round, and round, and round, and round....
> 
> yeah thats right. maybe there should be some challenge mechanism that will
> not kill/nick change anyone until it gets reply from the lagged server?

Ahh but that leads to another prob... 20-30min lagged servers....?  It
has been known....

however you could take a bit more CPU up, and FNC both nicks then mark
them, then if one of the nicks changes to the others nick kill it only.

ie:

Client A = Nick Guest
Client B = Nick Guest
Collision!
Client A under FNC changes to Guest2345
Client B under FNC changes to Guest5432
Both servers inform each other of the change. Before the FNC happens.
Client B then gets Client A's new nick and changes to it:
Client B Changes From Guest5432 to Guest2345
Msg from Client A's Server indicates the new nick the FNC resulted in,
then follows with the NICK Guest2345 message.
Collision 2!
Client B is killed, with no further notice.  As Client B's server has
seen the change from Guest5432 to Guest2345 - and only cause of that
change.
Client A knows nothing of the second colision.

Of course for this to work, it must be Client B's server being the
lagged one.  Unless all servers recognise the FNC messages and watch for
the collision, that shouldn't be too difficult.

The other problem is Client B FNC's to Guest5432 then changes to Guest
then Guest2345...  It'll have to be coded _REAL_ carefully, and well
though out for it to work.

Yours

Mickey