View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001933unrealircdpublic2004-07-09 00:222004-11-25 19:05
ReporterZ3l3zT Assigned Tocodemastr 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Platformi386OSFreeBSDOS Version5.2.1-RELEASE-p9
Product Version3.2.1 
Fixed in Version3.2.3 
Summary0001933: "set::allow-userhost-change force-rejoin;" allow banwalks?
DescriptionSure, it is set to FORCE-rejoin, but yet I find this quite strange, if "set::allow-userhost-change" is set to force-rejoin, and a user is banned from a channel, yet he rejoins without a problem when he set/unset +x .. it might be a weak configuration by me, but yet, it can be exploited to flood/spam a channel? Like a (odd) example, if a channel is attacked with a botnet, you can +l to lock them out, +i to lock them out, +m to make them quite, etc.. yet they can simply set/unset their +x modes to join/part flood the channel. Here's an example:

-- snip --
barfoo sets mode: +i
barfoo sets mode: +l 1
barfoo sets mode: +b *!*@c-2ce130e5.042-05-6e72632.cust.bredbandsbolaget.se
Parts: foobar ([email protected]) (Rejoining because of user@host change)
Joins: foobar ([email protected])
-- snip --

Is this "my own fault" or is it a "bug" ?
Steps To ReproduceSee description.
TagsNo tags attached.
3rd party modules

Activities

codemastr

2004-07-09 00:45

reporter   ~0006936

This can't be used to exploit anything. The user never really left, it's a simulated rejoin. And if you kick the user, they can't rejoin. So I don't see the problem.

Z3l3zT

2004-07-09 00:51

reporter   ~0006937

The idea was more like, when a botnet attacks a channel.. let's say you have 150 hostile bots in your channel.. then you can easily set +iml1 to "halt" the attack.. all they can do then is parting the channel or leaving the network to do a "flood" again.. but with this option enabled, they can simply set +x and they have just flooded the channel with 300 lines of text.. and as simply as before, just unset +x .. but sure, it's quite easy to disable by not having it to "force-rejoin", but yet, I think you should consider some way to fix that.. Like checking against the banlist if the user is banned (even if it's just simulated) and refuse it to join again in case it's banned.. or? Am I just too paranoid now? :)

syzop

2004-07-09 09:34

administrator   ~0006942

I see. I can understand your concerns now... instead of disallowing pretty much any traffic except a part (assuming you would have set +N too) they can still semi-flood with rejoins.

I'm thinking about the following (slight variation on what you suggested):
don't allow people to +x/-x if they wouldn't be allowed to rejoin (actually: +v or lower and banned or prevented by some channelmode, it makes sense to me to still allow +hoaq to rejoin). Oh and if the user IS allowed, do our rejoin trick :).
To implement this we would need (in a nice seperate function):
a loop which goes to the channels and checks if +v or lower, then if the user is banned or if any of the channel modes apply or if the PRE_LOCAL_JOIN hook returns HOOK_DENY.
We can't exactly use can_join directly... like we don't want it to suddenly use +L and join another channel (but we do want to check for +l), and actually it shouldn't check for the correct key either (but we could simulate that ;p).
We could add a flag to can_join or code a seperate thingy, the former doesn't seem too bad.
Then.. our nice "check if +v or lower and prevented from rejoining anywhere"-function would loop trough chans: call can_join(), call PRE_LOCAL_JOIN, and that's pretty much it... and then set some flag that a rejoin is in progress since stuff like:
if (UHOST_ALLOWED == UHALLOW_REJOIN)
    rejoin_dojoinandmode(sptr);
isn't that easy anymore ;p.

codemastr: any objections?

codemastr

2004-07-09 12:34

reporter   ~0006948

I don't really like the idea. It seems like it will confuse users. "You can't set +x because you are banned from #test" You don't see that as being confusing? I doubt any user will see that +x has anything to do with #test. I can see how this could cause a flood, and therefore should be addressed, I'm just not sure that's the best way to do it. Remember too, +x isn't the only thing that triggers that rejoin code. "You can't /oper because you are banned on #test," "You can't use /vhost because you are banned on #test," "You can't /chghost on foobar because foobar is banned on #test," etc. Then of course we have the issue of U:lines. What happens if a U:line sends the command? Do we just allow it through? If so, then /ns set vhost (or whatever the command the services use) could be used to flood just as well. And rejecting it would cause problems as well. The services assume SETHOST succeeds, so it auto sets the vhost locally. So if we make it fail on the IRCd, now we have desync.

I'm really not too sure how to deal with this...

syzop

2004-07-09 12:41

administrator   ~0006949

> don't really like the idea. It seems like it will confuse users. "You can't set +x because you are banned from #test" You don't see that as being confusing? I doubt any user will see that +x has anything to do with #test.

Well, isn't UHALLOW_NOCHANS similary confusing? :P

I'm in a hurry, so I didn't really read the rest properly, but if you say it doesn't help much anyway due services/others then yeah.. that sucks ;).
But do you see the problem he talked about? I think it's quite real.
(Then again, chanmode f should have prevented hundreds of bots from joining in the first place ;p)

I was looking for something between UHALLOW_NOCHANS and UHALLOW_REJOIN.

aquanight

2004-07-09 15:45

reporter   ~0006955

well why not...

if the user is banned/whatever, just don't send the part/join. The host still gets set, but it can't flood by simply using the rejoin aspect of +x.

codemastr

2004-07-09 18:22

reporter   ~0006958

I kind of like aquanight's solution. No flood, and they can still change their host. And really, we could even still send the JOIN/PART to all the other channels so the IAL desync is as small as possible. Plus, usually, if you are +b'ed the /kick isn't too far away :) so the problem is even less serious.

aquanight

2004-07-09 18:34

reporter   ~0006960

>And really, we could even still send the JOIN/PART to all the other channels so
>the IAL desync is as small as possible.

My thoughts exactly ^_^ . Of course, said "desync" really only occurs with clients that have an IAL... need I bring up telnet here (if that counts as a client that is :P )?

>Plus, usually, if you are +b'ed the /kick isn't too far away :) so the problem
>is even less serious.

Well, you can't really say that's always true. There's still the +bquiet techinique (and while ~q handles that well, straight +b blocks "other forms" as well. Better one ban than two where possible ;) ). And on the other hand, when /kick isn't too far away, it's usually /ban -k - IOW immediately :P .

aquanight

2004-07-17 00:55

reporter   ~0007117

I did a tad bit of thinking here...

Considering the whole purpose of this... preventing part/join flooding by changing host... I had that thought that "mute" users were just as likely to host-flood as banned users... so do you think +mM should have some kind of effect as well? :)

codemastr

2004-07-17 12:17

reporter   ~0007124

aquanight, no. If I'm +b and I type /part #chan, /join #chan, it will fail (because I'm banned). If the channel is +m and I do that, it will succeed. Hence, the flood is "natural." If they want to stop that, then they'd set +b on the user.

aquanight

2004-07-17 18:25

reporter   ~0007133

True... as I said, it was just a thought...

codemastr

2004-11-25 19:05

reporter   ~0008414

Added in .194

Issue History

Date Modified Username Field Change
2004-07-09 00:22 Z3l3zT New Issue
2004-07-09 00:45 codemastr Note Added: 0006936
2004-07-09 00:51 Z3l3zT Note Added: 0006937
2004-07-09 09:34 syzop Note Added: 0006942
2004-07-09 12:34 codemastr Note Added: 0006948
2004-07-09 12:41 syzop Note Added: 0006949
2004-07-09 15:45 aquanight Note Added: 0006955
2004-07-09 18:22 codemastr Note Added: 0006958
2004-07-09 18:34 aquanight Note Added: 0006960
2004-07-17 00:55 aquanight Note Added: 0007117
2004-07-17 12:17 codemastr Note Added: 0007124
2004-07-17 18:25 aquanight Note Added: 0007133
2004-11-25 00:31 codemastr Status new => assigned
2004-11-25 00:31 codemastr Assigned To => codemastr
2004-11-25 19:05 codemastr Status assigned => resolved
2004-11-25 19:05 codemastr Fixed in Version => 3.2.3
2004-11-25 19:05 codemastr Resolution open => fixed
2004-11-25 19:05 codemastr Note Added: 0008414