Background

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:

However, not all letters take an argument. For example, this:

This is described in details here in the specification

The bug

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:

1. if this is a mode declared in ISUPPORT PREFIX, then expect an argument
2. if it is mode "b", "k", or "l", then expect an argument
3. otherwise, expect no argument

This can be tricky to exploit, so here are several examples below, in order of increasing complexity.

Example 1: Muting and opering

When a channel operator sends the following command:

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:

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.

Example 2: de-opping not being applied

When a channel operator sends the following command:

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:

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.

Example 3: opping the wrong person

The following command:

but is interpreted by node-irc/matrix-appservice-irc as:

This is of little consequence, as far as I can tell; for the same reason as before

Example 4: Evading the "protected" channel mode

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:

but is interpreted by node-irc/matrix-appservice-irc as:

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.