New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nick-/ChanServ: Registering "clear", "modify" or "list" breaks /msg ChanServ flags #channel clear/modify/list #397

Closed
ToBeFree opened this Issue Nov 2, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@ToBeFree
Contributor

ToBeFree commented Nov 2, 2014

There is some kind of ironic "Anope compatibility" implemented in ChanServ here:
https://github.com/atheme/atheme/blob/master/modules/chanserv/flags.c#L195

It seems to be a feature, but it is completely weird, that any user can register the nicks "clear", "modify" and "list", resulting in a network-widely changed command syntax:

before registration:

"/msg ChanServ flags #channel list"
--> shows the flags for #channel
"/msg ChanServ flags #channel modify Username +-modification"
--> modifies the flags for Username on #channel
"/msg ChanServ flags #channel clear"
--> clears the channel's flags (!)

after registration:

"/msg ChanServ flags #channel list"
--> shows the flags for the user who grouped the nick "list"
"/msg ChanServ flags #channel modify Username +-modification"
--> [ChanServ] Invalid template name given, use /msg ChanServ TEMPLATE #channel for a list (!)
"/msg ChanServ flags #channel clear"
--> shows the flags for the user who grouped the nick "clear"

issues caused by this behavior:

This is highly theoretical, but it could actually lead to annoyance in certain cases:

  • If Alice uses the nick "clear" and the founder of #channel wants to give them privileges, Alice could quickly drop/ungroup their "clear" nick to cause the founder to clear their whole #channel flags list. This can be very annoying and hard to restore. As it - as far as I know - also includes all AKICK entries, it could even be abused to cause the founder to unban all people on the AKICK list.
  • If there is someone who has a nick that matches a template, the FLAGS MODIFY command can be abused. Let's say someone added "lover" as a template for +AVeiorstv in their #channel (this actually happened). This someone is used to the Anope compatibility syntax and wants to give the user "LoVeR" the +V flag, and nothing more.

This someone now wants to use the following command to first check the current flags of LoVeR:
/msg ChanServ flags #channel modify LoVeR
--> Expected result: [ChanServ] No flags for LoVeR in #channel.
Then they would like to use "/msg ChanServ flags #channel modify LoVeR +V" to give them the needed flag.
However, LoVeR quickly and silently - for example using an identified webchat in the background - groups the "modify" nick to their account. Now someone uses the command:
/msg ChanServ flags #channel modify LoVeR
...to see LoVeR's flags on #channel, as that has always worked like this. They got used to this Anope command syntax and are happy to be able to use it here, too. However, as "modify" is now grouped, the command will produce the following result:
--> [ChanServ] Flags +AVeiorstv were set on LoVeR in #channel.
Whoops, LoVeR got some permissions they should not have received, by changing the behavior of a services command just by grouping the "modify" nick to their account. Before someone understands what happened, LoVeR abuses their privileges.

As I said, it's a highly theoretical issue, but in my opinion, it should be fixed anyway. It should not be possible for users to change the behavior of services commands by registering nicks that happen to match command names.

@kaniini

This comment has been minimized.

Show comment
Hide comment
@kaniini

kaniini Nov 2, 2014

Contributor

This is rejected for Atheme, please consider reporting it to a downstream fork instead.

Contributor

kaniini commented Nov 2, 2014

This is rejected for Atheme, please consider reporting it to a downstream fork instead.

@kaniini kaniini closed this Nov 2, 2014

kaniini added a commit that referenced this issue Nov 2, 2014

kaniini added a commit that referenced this issue Nov 2, 2014

Revert "Fix #397"
This reverts commit ed32a1e.

ToBeFree added a commit to ToBeFree/atheme that referenced this issue Mar 5, 2016

Remove problematic Anope "compatibility". See comment
Moved to a comment because Atheme might not be using GitHub in the future.

Fixes GitHub issue atheme:#397
@ToBeFree

This comment has been minimized.

Show comment
Hide comment
@ToBeFree

ToBeFree Mar 5, 2016

Contributor

[This issue is not fixed until the patch is merged. It was closed for now obsolete reasons.]

Contributor

ToBeFree commented Mar 5, 2016

[This issue is not fixed until the patch is merged. It was closed for now obsolete reasons.]

maxteufel added a commit that referenced this issue Mar 6, 2016

chanserv/flags: make Anope FLAGS compatibility an option
Previously, ChanServ FLAGS behavior could be modified by registering or
dropping the keyword nicks "LIST", "CLEAR", and "MODIFY".
Now, a configuration option is available that when turned on (default),
disables registration of these keyword nicks and enables this
compatibility feature. When turned off, registration of these keyword
nicks is possible, and compatibility to Anope's FLAGS command is
disabled.

Fixes atheme/atheme#397

maxteufel added a commit that referenced this issue Mar 6, 2016

chanserv/flags: make Anope FLAGS compatibility an option
Previously, ChanServ FLAGS behavior could be modified by registering or
dropping the keyword nicks "LIST", "CLEAR", and "MODIFY".
Now, a configuration option is available that when turned on (default),
disables registration of these keyword nicks and enables this
compatibility feature. When turned off, registration of these keyword
nicks is possible, and compatibility to Anope's FLAGS command is
disabled.

Fixes atheme/atheme#397

maxteufel added a commit that referenced this issue Mar 6, 2016

chanserv/flags: make Anope FLAGS compatibility an option
Previously, ChanServ FLAGS behavior could be modified by registering or
dropping the keyword nicks "LIST", "CLEAR", and "MODIFY".
Now, a configuration option is available that when turned on (default),
disables registration of these keyword nicks and enables this
compatibility feature. When turned off, registration of these keyword
nicks is possible, and compatibility to Anope's FLAGS command is
disabled.

Fixes atheme/atheme#397

siniStar7boy added a commit to XthemeOrg/Xtheme that referenced this issue May 8, 2016

chanserv/flags: make Anope FLAGS compatibility an option
Previously, ChanServ FLAGS behavior could be modified by registering or
dropping the keyword nicks "LIST", "CLEAR", and "MODIFY".
Now, a configuration option is available that when turned on (default),
disables registration of these keyword nicks and enables this
compatibility feature. When turned off, registration of these keyword
nicks is possible, and compatibility to Anope's FLAGS command is
disabled.

Fixes atheme/atheme#397
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment