[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Anti-collide patch




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?

pht