Several bugs in matrix-appservice-irc allowed malicious users to leak parts of past messages in a room they joined after the message was sent.
By default, on IRC and in Matrix rooms acting as a "portal" to IRC,
users are only allowed to see messages sent while they were in the channel/room (known as "m.room.history_visibility": "joined" on Matrix).
Matrix allows message events to reference the event id of another message that it is a reply to. The reply may contain the text of the replied-to message (known as the "reply fallback"), but this text is ignored, and being deprecated.
Because the IRC protocol traditionally does not support replies, this Matrix bridge often formats Matrix replies like this on the IRC side:
hello everyone, happy to be here [more messages]"hello everyone, happy..." <- welcome in this room ]]>
The hello everyone, happy... part in this reply is susceptible to leaks, as it repeats a past message to the current audience of the IRC,
which may be larger than the original audience.
Security-wise, I do not consider this an issue that if Bob could read Alice's message and replies to it, parts of Alice's message are repeated. I only see it an issue when Mallory, who cannot see the content of Alice's message, can craft an event that causes Alice's message to be repeated.
All of the vulnerabilities mentioned here require the attacker to know the event id of the message they want to leak. While event ids are not necessarily easy to obtain, they are considered public, as they can be part of matrix.to or matrix: URL shared publicly, and are shared with any homeserver joining a room, even if said homeserver does not have access to the event's content.
These vulnerabilities only allow leaking a small part at the beginning of the message, up to 32 characters.
This first bug happens because matrix-appservice-irc did not perform any check on the event being replied-to before including it in the reply. This allowed an attacker who knows the event ID to just send a reply to it in a room they control, and the replied-to message will be sent to the IRC channel.
Additionally, this allows leaking the nickname of the author of the replied-to message. In the Matrix model, this is only an issue if the attacker is not in the room; as any server in the room can tell who the author (and timestamp) of an event id is, even if they do not have access to the content of the event.
The fix was obvious: check the replied-to message is in the same room as the reply.
This bug comes from the fix to the previous bug being partial: it prevents crafting events to leak messages in a different rooms; but not leaking messages in the same room.
This means that someone can use it to access the same first 32 characters of any past event of a room, even if the room's history_visibility is not "world_readable". Though this time it has the precondition this attacker is currently in the room.
Shortly after I sent the report, Matrix.org's triaged it as a low priority issue, as 1. they considered event ids to be hard to find, and 2. only recent messages could be leaked this way.
However, a malfunction in Matrix.org's ticketing system, causing this information not to be sent to me,
adding three months of delay before I could answer 1. event ids are easy to obtain for someone running their own homeserver and 2. matrix-appservice-irc allows replies to messages indefinitely far away in the past.
This vulnerability was then fixed by checking the sender of a reply last join event predates the message being replied to.
The fix to the previous vulnerability was missing an important detail:
in Matrix, all event timestamps (aka. origin_server_ts) in Matrix are provided by the sender of the event.
Timestamps can be, somewhat intentionally, far back in the past,
as Matrix's data model is eventually-consistent, allowing their events to form
a DAG,
with some branches being potentially pretty old.
This allowed attackers to fake the timestamp of their join event,
so they could again leak any message they liked afterward, as
if (senderJoinTs > cachedEvent.timestamp) {" in the above patch would always pass.
Unlike the two bugs above, this requires the attacker to use a malicious homeserver,
which means private federations mostly not affected.
This is pretty tricky to fix, with three options:
matrix-appservice-irc developers proceeded with option 3.
Unfortunately, the previous fix was still incomplete, as it only keeps track of the 8192 most recent joins, and then falls back to assuming the user joined when the bridge started. Having an limit to the cache size makes sense to avoid memory growing unbounded; and falling back to the bridge start instead of the attacker-provided date avoids leaking very old messages.
However, this is not enough in practice. For example, the public OFTC bridge has about 20k users on the Matrix side; which means way more than 20k joins to keep track of as users are often joined to more than one room. (The 20k figure is not official, but can be obtained as it coincides with the number of users OFTC loses when the bridge restarts, which is visible on netsplit.de; up to July 2024 where they stopped auto-connecting idle users.) And as the OFTC bridge restarts only about once a month (again, can be see on netsplit.de), this means that most messages on OFTC can be leaked by someone joining a channel within a few weeks.
After I told this to Matrix.org's security team, they decided to reconsider the solution to the previous bug, and pick a variant of option 2 above, which is to make the bridge rely on the homeserver tell it what events a user is allowed to see. This makes sense as the homeserver already computes this information, it just does not make it available to the bridge. This is materialized by MSC4185: Event Visibility API, which is currently not implemented.