View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002345 | unreal | ircd | public | 2005-02-15 17:00 | 2007-04-27 05:32 |
| Reporter | Zell | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.2 | ||||
| Summary | 0002345: IRCOp /invite'ing others without being op'ed does not trigger any OperOverride notice | ||||
| Description | IRC Operators with the override flag can be on a channel and not have channel operator status, and the server will permit them to invite users other than themself to the room (even override a ban for that user) - and it does not send out any kind of notice (besides the standard notice to all channel ops). However, on a room where the ops are all offline or away, a malicious IRCop can sit in a room and invite users past bans, allowing them to banwalk. This will also override +k, +l, and +L. Such activity should be logged and/or notified! As current, if no channel operators are on the room, nobody will be notified of this invite (except the user being invited)! | ||||
| Steps To Reproduce | 1) be an oper w/ override flag 2) be on a room and not have +o 3) have a ban for *!*@* (a good way to test things) 4) /invite BannedDude #Channel 5) BannedDude joins #Channel, silently overriding +b | ||||
| 3rd party modules | |||||
|
|
[quote]malicious IRCop[/quote] Those two words should never be used together. I agree this problem should be addressed, but if you have malicious IRCops, then perhaps it's time to remove their access. |
|
|
before removing oper-access you have to know that there is a malicious ircop... in this special case I think it's a mixture of several things: - if there is no +i in channel (since it has not been mentioned otherwise I assume there is no +i...) - everybody can use /invite - so the oper uses /invite because he is allowed to use it like every normal user - since it is an oper-invite this invite is able to pass through bans and other join-blockings as well (a non oper invite would not bypass bans...) somewhere in this chain there should be a privilueges-check added, so an override-notice can be sent... |
|
|
but u dont need to have ops to use the /invite command, so techincally this is correct? |
|
|
imo it's half-correct... every user may use /invite in sense of "hey - this is a cool channel come on in!" (often abused for spamming channels for example...) so the ircd would have to do a detailed checkup in case of an oper-invite which I think is most difficult. ex.: #channel has mode: +b baduser!*@* - and no modes else the joined oper may invite "gooduser" since every user can invite their friends - no override has happened - no notice is necessary but if he likes to invite "baduser" he, the override-capable oper, would allow a banned user to get in My opinion: since an oper should know how to behave, it's not that critical I assume this small glitch here has propably been present in unrealircd for a very long time (don't wanted to dig out any old versions and test *ggg*) since nobody stumbled over that - this is most likely not even worth the work? *waiting for the contras of perfectionists* ;) |
|
|
Welllllll Actually.... Heh. Did some more testing.. /invite always allows banwalking. The only way to stop that is with the +V mode. I dont think it would be possible to prevent total abuse of this command. All invite commands cause ops-only notice to the room, which is enough right now. But, when you think that in many cases sometimes there arent any room ops, somebody might be f**ing with invite to allow banwalk. Fix: Set +V on your channel. Coders, i'm stuck on this issue. |
|
|
i tested as well an invite from a normal user just informes another user of the channel's existence . behaviour of /invite is different for opers - channelops and in case of channemode +i, but a channelop may remove the ban as well - there is no need for banwalk-helping (and always the same "choose your ops carefully"-story ;) ) but /invite is definitely not ALWAYS allowing banwalking! |
|
|
Hmmm.. I was thinking about doing this, like whenever an ircop /invite's print out a operoverride notice etc etc.. But... that's not a good idea I think, since an ircop can do a fully legal invite if the channel is just, say, +snt and no bans on the target user. So, in order to have this work properly we would have to check if the target user cannot "normally" join, which would require many more code than this simple fix :P. Hm, I see medice pointed that exact issue out already. Therefore, I think I'll just leave it as-is for now, it's not something I want to let break 3.2.3 :P. |
|
|
What I wonder is, why is an IRCop's invite (even when not opped) considered enough to let a user through bans/etc? I can understand the can_override aspect, but are they overriding anything when they are just normally inviting a user? (eg, any normal user can /invite and that doesn't let people through bans, etc.) I just don't know if it makes sense for an ircop's (w/ can_override, this whole "bug" doesn't work at all when you're like me and #define NO_OPEROVERRIDE :P ) invite to be enough to let users walk bans/etc? *edit* Erm, just remembered... ChanServ >_> . Ok, ULines are one thing. IRCops are another :P . */edit* |
|
|
Hm, indeed. Reran checks. User1 is not Opered, and is banned. User2 not opered and is on channel without ops. User 3 is operator at channel. User 2 invite User 1 No Notice sent at all to ops (verified by User 3) User 1 unable to join (banned) User 2 /oper up User 2 invite User 1 Notice IS sent to chanops (but does NOT say "override") User 1 joins channel (hi, banwalking) Using this, suppose User3 was not available or was offline, anyone can banwalk through a evildoing Halfop or IRCop with override priv's. More interestingly, the Notice was only sent once User2 became IRCop. Still, it should say OperOverride if any bans or limitating modes are set that could ban the user from joining (notice the channel as if the operator was overriding for himself.) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-02-15 17:00 | Zell | New Issue | |
| 2005-02-15 17:30 |
|
Note Added: 0009153 | |
| 2005-02-15 17:56 | syzop | Summary | [Security] Invite security hole found => IRCOp /invite'ing others without being op'ed does not trigger any OperOverride notice |
| 2005-02-16 05:15 | medice | Note Added: 0009155 | |
| 2005-02-16 11:59 | White_Magic | Note Added: 0009156 | |
| 2005-02-16 13:28 | medice | Note Added: 0009157 | |
| 2005-02-17 17:41 | Zell | Note Added: 0009158 | |
| 2005-02-17 17:58 | medice | Note Added: 0009159 | |
| 2005-02-28 16:06 | syzop | Note Added: 0009369 | |
| 2005-03-01 13:43 | aquanight | Note Added: 0009382 | |
| 2005-03-01 13:44 | aquanight | Note Edited: 0009382 | |
| 2005-03-01 20:34 | Zell | Note Added: 0009387 | |
| 2006-01-16 15:42 | syzop | Relationship added | child of 0002748 |
| 2006-04-02 16:48 | syzop | Relationship deleted | child of 0002748 |
| 2007-04-27 05:32 |
|
Status | new => closed |
| 2007-04-27 05:32 |
|
Resolution | open => no change required |
