Re: W_Knight strikes again

[Donald Quixote VI <holeekow@xxxxxxxxx>]

hi saso..

I'm sorry but on this one, it appears you do not understand how opcheating
works.

You said:

"The eggdrop that received the op request goes and (stupidly,
since any human op wouldn't do that if they see a nick sign off and
another client taking their nick) ops the nick without checking if the
present client holding the nick is having the same user@host mask as the
client that requested ops."

Whether bot or op or by scripted client, please be sure that the hostmask
is ALWAYS tested before auto-sending the +o mode.  The propensity for human
ops manually opping an impostor is not at issue here.

The issue becomes an ircd issue because +o modes are just sent to nick, not
to nick!ident@xxxxxxxxxxxx

AFTER the hostmask is tested and matched, a +o mode is sent.
AFTER it is sent, again -- ONLY AFTER matching the hostmask, the target
quits whether from flooding or nuking or whatever.

While +o modes being transmitted over the net, sent to the rightful nick at
the time, the target quits and the impostor immediately steals the nick of
the rightful op.

At this time, it is tru that the impostor's host mask does not match the
target, but it is too late.  After matching to the right op, the the +o was
sent, BEFORE the impostor stole the nick.

That is why locking out the nick of ops/bots that quit for a period of 1 to
15 minutes, similar to the split nick lockout, would be effective.  It
would prevent an impostor stealing the nick and receiving the +o that had
been sent to the right target.

Also, having the server autosend a -o mode on ops that quit would help
cancel any lagged +o modes still floating.

If you doubt the process still, I have megabytes upon megabytes of logs
showing this abusive tactic.

Were it easily handled at the chanop level, I would not have the gaul to
present the issue to you and others.

It was only after discussing it with the ircd programmer and following his
request that I wrote about this.

No offence meant..  but it is the +o by nick only at the ircd level that is
being exploited.  The scripts and bots check for host before sending the +o
mode change.

regards

TomCollns
LoBo^LoCo

==========================================================
At 09:39 PM 3/27/98 +0100, Saso Virag wrote:
>On Thu, 27 Mar 1997, Donald Quixote VI wrote:
>
>> >> Have you received any feedback as to other possible solutions to this
>> >> loophole?
>> >
>> >+i +s and NO auto-ops should work fine.
>> >
>> >Piotr/Beeth@xxxxxx
>> >
>> >
>> 
>> While reducing or elimiating auto-ops might help, Op cheating works without
>> auto-ops, and even without flooding.
>> 
>> W_Knight has been known to nuke 1 op, repeatedly who is in the process of
>> requesting ops, and then, as soon as the target op quits, W_K steals the
>> ops nick and can intercept a single +o sent to the rightful op.  No
>> auto-ops, just an op requesting ops.
>> 
>> You can't run a large public channel +i.  That kills a channel.
>> Temporarily, yes, but not for long periods.
>
>Lets call a BOT a BOT and not an op for the sake of the conversation. So
>one eggdrop send request for ops and w_knight takes that bot down in the
>next moment. The eggdrop that received the op request goes and (stupidly,
>since any human op wouldn't do that if they see a nick sign off and
>another client taking their nick) ops the nick without checking if the
>present client holding the nick is having the same user@host mask as the
>client that requested ops.
>
>All in all an eggdrop bug. Or a feature. :)
>
>No place for such discussion on ircd list. take it to eggdrop list.
>
>Have a nice day.
>
>-me 
>
>
>-									-
> Saso Virag * System Administrator @ SiOL.net - Telekom Slovenije OnLine
>		     System Administrator @ EUnet.si
>	   IRCAdmin @ irc.SiOL.net - RA^v^EN / Guest7 @ IRCNet
>			E-mail : Saso@xxxxxxxx
>-									-
>
>
>