The MODE command is used in the IRC protocol to change channel properties and permissions.
It has the following syntax:
[[ ...]] ]]>
and the <modestring>
is made of letters. For example, this:
is equivalent to:
which bans (
+b
) "baduser" and adds "gooduser" to channel operators (+o
).
However, not all letters take an argument. For example, this:
is equivalent to:
which sets the channel to moderated mode (
+m
), and adds "gooduser" to channel operators (+o
).
This is described in details here in the specification
Clients should rely on ISUPPORT CHANMODES to know which letters expect an argument.
However, even though node-irc parses ISUPPORT CHANMODES and ISUPPORT PREFIX, it did not actually use them to parse MODE commands.
Instead, it relied on the following algorithm:
This can be tricky to exploit, so here are several examples below, in order of increasing complexity.
When a channel operator sends the following command:
this means, on Solanum (the server used by Libera.Chat), that the server should quiet (
+q
) "baduser" and make "gooduser" an operator (+o
).
However, because of step 3 of the algorithm above, node-irc / matrix-appservice-irc assumes q
takes no argument, so it parses it as equivalent to:
which would make "baduser" an operator
However, this is severely limited by an implementation detail of Solanum: when used as argument of +q
, "baduser" is actually rewritten to "baduser!*@*" before being sent to matrix-appservice-irc.
I was not able to find a way to exploit this, as all common IRC servers either append "!*@*" arguments or validate them, so they cannot be nicknames. It is an implementation detail and not guaranteed by the protocol, though.
A big caveat: this is somewhat pointless, as it would very unusual for channel operators to send +qo
as a single command; and malicious operators could mess with the channel is other ways.
When a channel operator sends the following command:
this means that the server should unset the channel user limit (
-l
) and remove "disgraceduser" from the operators.
However, because of step 2 of the algorithm above, node-irc/matrix-appservice-irc assumes "l" takes an argument (which is true of +l
, but not of -l
), so it parses it as equivalent to:
causing the last line to be ignored, and "disgraceduser" is not removed from the operators.
The consequence is that, if "disgraceduser" is connected from Matrix, they will keep their power over the Matrix room. Either way, they will also appear to other clients as room moderator, but this is without any meaningful consequences, as far as I can tell. (Though it could be abusable if any Matrix bot gives power based on apparent power level, like BitBot does on IRC? I am not aware of any example of this.)
Same caveat as before.
The following command:
is equivalent to:
but is interpreted by node-irc/matrix-appservice-irc as:
making "niceuser" an operator instead of "gooduser"
This is of little consequence, as far as I can tell; for the same reason as before
If "gooduser" has both channel modes +a
("protected") and +o (operator), normal operators cannot remove their operator status.
(This may be true as well for servers with implement +q
as "channel owner", but I did not test it)
However, operators can remove it from their Matrix users if mode +a
is not configured in the modePowerMap
:
The following command:
is equivalent to:
(which is legal for operators, even if "gooduser" is protected)
but is interpreted by node-irc/matrix-appservice-irc as:
(which isn't)
This allows malicious channel operators to remove privileges from "protected" Matrix users, and make it look like to Matrix users they removed privileges from other (IRC or Matrix) users.
This means that, under very specific circumstances, matrix-appservice-irc could interpret some users as being made operators, or miss that they are removed from operators. When such users are Matrix users, it may give them power they should not have over Matrix rooms.
This is, however, very limited, because (besides in the example of the uncommon "protected" mode), the user sending commands must have power superior or equal to the attacker; so this can only be triggered accidentally, or by tricking IRC channel operators into typing and running these commands.
As an aside: yes, the MODE
command is tricky to use and parse.
I authored the draft named-modes
IRCv3 specification, a work-in-progress to address both the mode character/parameter matching issue, and the ambiguity of mode characters.
You can help by supporting its implementation in your favorite clients and servers.
NVT#1532845
).NVT#1536508
by the ticketing system)NVT#1537667
by the ticketing system)NVT#1537840
by the ticketing system)