View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006400 | unreal | ircd | public | 2024-04-20 21:20 | 2024-04-22 10:26 |
| Reporter | Koragg | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 6.1.4 | ||||
| Summary | 0006400: ~forward extban and +L chmode do NOT validated if setter has access in targetted channels | ||||
| Description | The ~forward:#other extban as well as the +L #other channel mode do NOT verify if the person setting them in their own channel has (half)ops or higher in the #other channel. This would allow people to forward spambots, trolls etc from their own channel into other channels without validating if they are permitted to do so. | ||||
| Steps To Reproduce | 1. a) have two channels, #mychan where the mode is set in, #otherchan being the "targetted" channel (the one users get redirected to) b) make sure to have (half)ops or higher in #mychan and have NO (half)ops or higher (voice or no status) in #otherchan 2. a) for the ~forward:#otherchan issue perform: /mode #mychan +b ~forward:#otherchan:*!*@bad.host.name.here b) for the +L issue perform: /mode #mychan +L #otherchan 3. observe that in both cases, a) and b) the mode is set without any interference by UnrealIRCd that one does NOT have (half)ops or higher in #otherchan 4. expected output: a numerical error (perhaps additionally a standard-replies error for modern clients?) stating something along the lines of: "You do not have permission/access to forward/redirect users to #otherchan" | ||||
| Additional Information | The reason this is filed as an issue is that other implementations (InspIRCd via a contrib module, solanum/charybdis natively) DO perform such an access check ensuring that the person setting such a forward in #mychan also has (half)ops or higher in #otherchan . UnrealIRCd is the one in this case with conflicting behavior. Others (PeGaSuS, Valware for example) also agreed should be changed accordingly as it is not seen as the logical way to permit anyone to redirect users to any channel without sufficient access in said #otherchan Tested on UnrealIRCd-6.1.4. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Let me start by saying that some other ircds, for indeed a looong time, have some modes like a "no forward" user mode or a "you can't forward to this channel" channel mode. Those are not what you are suggesting, but I just wanted to state that I've always felt that those are over-the-top, i feel like they are a waste of modes for a problem that is only marginal. Adding a check to validate access of the setter (eg +hoaq) on the channel-to-be-forwarded-to is much nicer and is something that is easy to do. But what about Services? When Services send a MODE the IRCd can only see it comes from services, not from which underlying person, and thus cannot check if that person has rights in the other channel. For those other IRCds, do Services like anope and atheme (or the IRCd somehow) take care of that, or do they allow you to bypass the restriction via CS MODE #source SET +L #target (for +L) and via AKICK ADD (for ~forward)? If that case is covered I'm fine with adding the check, it sounds like a good idea. If the Services-case is not covered then I would rather not give a false sense of "security" if it can be so easily bypassed. |
|
|
So, as for ~forward it has no effect if you do `/cs akick #channel add ~forward:#target:*!*@bad.host.name`, so the user can still join the channel. Unfortunately, there's no check (at least on Anope) to prevent users from using `/cs mode #channel set +L #target` or `/cs mode #channel set ~forward:#target:*!*@bad.host.name`. I will open a feature request for a check when using `CS MODE SET`, at least, for the +L mode on Anope. |
|
|
If there's a bypass in Services for those other IRCd's then you can bother anope indeed (then it has nothing to do with unrealircd). You can't bother them about the unreal module, though, can only ask them to restrict +L in Services after/if we have decided to restrict +L ourselves in the IRCd.. and we are not 100% there yet. Valware brought up the question by the way: should this be configurable? Now any time I bring up configurability of any option up there is always someone who says "YES!". But making something configurable also has downsides: the restriction in services then has to match the restriction in the ircd, it also makes it more ambiguous for users and documentation needs those remarks like "this may or may not have a restriction". If we go the way of adding this restriction then I am leaning to making it not configurable and just always have this new restriction thing. QUESTION: Are there good reasons to allow the old/current behavior, reasons someone could not live with the new restriction? Happy to hear! |
