Summary

Because of a bug in matrix-org/node-irc, matrix-appservice-irc could be abused to mute room and make private rooms publicly accessible.

Background

The IRC protocol is based on lines, delimited by <CRLF> (aka \r\n); and parameters within a line are delimited by a space character. When a parameter starts with a colon (:), it means the rest of the line is part of that parameter; that parameter is called the trailing.
Within a parameter, any character other than null characters, carriage returns, line feeds, and spaces are allowed.

Here is the grammar used in the current specification:

  middle          ::=  nospcrlfcl *( ":" / nospcrlfcl )
  trailing        ::=  *( ":" / " " / nospcrlfcl )
]]>

The specification contains a few examples of IRC messages, and how they should be tokenized in JSON-like syntax:

  ["*", "LIST", ""]

  CAP * LS :multi-prefix sasl       ->  ["*", "LS", "multi-prefix sasl"]

  CAP REQ :sasl message-tags foo    ->  ["REQ", "sasl message-tags foo"]

  PRIVMSG #chan :Hey!               ->  ["#chan", "Hey!"]

  PRIVMSG #chan Hey!                ->  ["#chan", "Hey!"]

  PRIVMSG #chan ::-)                ->  ["#chan", ":-)"]
]]>

The bug

matrix-appservice-irc uses a fork of the node-irc library, which tokenizes the trailing parameter by detecting a colon preceded by any whitespace (such as &CTAB;, the tabulation character).

This mismatch means that a parameter containing a non-space whitespace followed by a colon is parsed by node-irc as being partly the start of the trailing.

For example, this IRC line:

:moo :Hey!
]]>

:moo", "Hey!"]
]]>

This means someone (whether they are in &CHAN; or not) could make matrix-appservice-irc believe they sent messages to &CHAN;, by sending messages to &CHANMOO;, assuming Matrix puppets of the same bridge are both in &CHAN; and &CTAB;

Basics

On IRC, channel state is changed via the MODE command, which has this syntax:

 [ [...]]
]]>

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.

IRC servers validate the content of the <modestring> to exclude characters they do not understand, which means &CTAB; and colons cannot be used there. I also could not find a way to use it in a <mode arguments> in any interesting way. This left <target>.

Unsurpringly, neither Matrix nor most IRC servers like &CTAB; in room/channel names. However, some IRC servers do allow it, including:

• InspIRCd
• ircd-hybrid and most of its forks (including oftc-hybrid)

• Charybdis and its forks (such as Solanum, Libera.Chat's server).
• Ergo
• UnrealIRCd

Finally, to exploit this, one needs to make a Matrix puppet join a channel with &CTAB; in its name. My first thought was to exploit one of IRC's "channel forward" features; such as Solanum's +f mode or UnrealIRCd's ~forward extban; but ircd-hybrid supports neither.

Therefore, I initially concluded this was not exploitable, and submitted a simple bug fix; which was accepted.

Exploit 1: muting Matrix users

A month later, I found out that matrix-appservice-irc has a !cmd command; which allows making one's IRC puppet join arbitrary channels. Though Matrix clients generally do not allow typing &CTAB; in a message; it is possible to send a raw Matrix event like this:

Once a Matrix puppet is in &CHANMOO;, operators of &CHANMOO; can send MODE commands to that channel, such as:

:moo +b :baduser!*@*
]]>

apply mode b (ban) to baduser!*@* on &CHANMOO;)

Instead, it is parsed by node-irc as ["#chan", "moo +b :baduser!*@*"], ie.

apply mode characters m, o, o, (space), b, (space), :, etc. to &CHAN;,

Most of these mode characters are ignored by matrix-appservice-irc; but m is interpreted as the moderated channel mode, which means unprivileged users are muted. As a consequence, matrix-appservice-irc alters the power levels of any room bridged to &CHAN;, so users with power level 0 (the default) cannot speak anymore.

This can also be used to undo modes: by using #chan&TAB;-m instead, matrix-appservice-irc believes mode m is removed, so it restores the normal power level.

Exploit 2: making rooms public

Possibly a worse example of this, is with #chan&TAB;-i: this makes matrix-appservice-irc believe mode i (invite) is removed, causing it to make any bridged Matrix room joinable by anyone, instead of being invite-only.

This is somewhat limited by matrix-appservice-irc's design: after someone would join the (now public) Matrix room, matrix-appservice-irc would make its puppet join the IRC channel, which would fail (because the channel is still invite-only), so the Matrix user would be kicked out of the room within seconds (assuming no federation lag). If the user operates their own (malicious) Matrix homeserver and/or causes a DoS to the Matrix homeserver hosting the bridge, this could allow them to retrieve significant part of the history metadata (though not message content, assuming the room is not too old and is properly configured).

Other exploits

Aside from PRIVMSG and MODE, other commands may have been abusable, such as KICK (on servers thatallow the absense of kick messages), PART (ditto, to pretend you left a channel), INVITE (to invite only yourself to a room).

Nothing noteworthy as far as I can tell.