A Matrix Update Patches Serious End-to-End Encryption Flaws

Developers of the open source Matrix messenger protocol have released an update to fix critical end-to-end encryption vulnerabilities that subvert the confidentiality and authentication guarantees that have been key to the platform’s meteoric rise.

Matrix is a sprawling ecosystem of open source and proprietary chat and collaboration clients and servers that are fully interoperable. The best-known app in this family is Element, a chat client for Windows, macOS, iOS, and Android, but there’s a dizzying array of other members as well.

Matrix roughly aims to do for real-time communication what the SMTP standard does for email, which is to provide a federated protocol allowing user clients connected to different servers to exchange messages with each other. Unlike SMTP, however, Matrix offers robust end-to-end encryption, or E2EE, designed to ensure that messages can’t be spoofed and that only the senders and receivers of messages can read the contents.

Matthew Hodgson—the cofounder and project lead for Matrix and the CEO and CTO at Element, maker of the flagship Element app—said in an email that conservative estimates are that there are about 69 million Matrix accounts spread throughout some 100,000 servers. The company currently sees about 2.5 million monthly active users using its Matrix.org server, though he said this is also likely an underestimate. Among the hundreds of organizations announcing plans to build internal messaging systems based on Matrix are Mozilla, KDE, and the governments of France and Germany.

On Wednesday, a team published research that reports a host of vulnerabilities that undermine Matrix’s authentication and confidentiality guarantees. All of the attacks described by the researchers require the aid of a malicious or compromised homeserver that targets the users who connect to it. In some cases, there are ways for experienced users to detect that an attack is underway.

The researchers privately reported the vulnerabilities to Matrix earlier this year and agreed to a coordinated disclosure timed to Wednesday’s release by Matrix of updates that address the most serious flaws.

“Our attacks allow a malicious server operator or someone who gains control of a Matrix server to read the messages of users and to impersonate them to each other,” the researchers wrote in an email. “Matrix aims to protect against such behavior by providing end-to-end encryption, but our attacks highlight flaws in its protocol design and its flagship client implementation Element.”

Hodgson said he disagrees with the researchers’ contention that some of the vulnerabilities reside in the Matrix protocol itself and asserts they are all implementation bugs in the first generation of Matrix apps, which include Element. He said that a newer generation of Matrix apps, including ElementX, Hydrogen, and Third Room, are unaffected. There are no indications that the vulnerabilities have ever been actively exploited, he added.

Breaking Confidentiality, Attacking Verification, and More

The first two attacks provide a simple confidentiality break by exploiting the homeserver’s control over the users and devices that are permitted to join a private room. Only a person who creates a room or is deputized by the room creator is permitted to invite and admit new members, but the room management messages that make this mechanism possible aren’t required to be authenticated with the cryptographic keys of these authorized users. It’s trivial for someone with control of the homeserver to spoof such messages and, from there, admit users without the permission of the authorized users. Once admitted, the attacker gains access to decrypted communications sent in that room.

The researchers are careful to note that all new room entrants are automatically logged in an event timeline and hence can be detected by anyone in the room who manually inspects the membership list in real time. In large rooms with lots of activity, however, this kind of inspection may not be practical, the researchers said.

A variation of this attack is for the homeserver to add a device under the attacker’s control to the account of a user already in a private room. In a case like this, the new device will be displayed and labeled as “unverified” to all users, but at that point, all existing devices will automatically share the keys needed to decrypt all future messages.

A third proof-of-concept exploit provides an attack on the out-of-band mechanism Element offers so users can verify that the cryptographic identity they’re communicating with matches the person they think it does. This verification allows users or devices to compare short authentication strings to make sure they match, in much the way that the Signal messenger uses safety numbers. In either case, users perform the comparison outside of the app.

The researchers wrote:

Our attack against out-of-band verification in Matrix enables an attacker to convince a target to cryptographically sign (and thus verify) a cross-signing identity controlled by the attacker. In this attack, a malicious homeserver assigns each device a device identifier that is also a valid cryptographic identity (under the homeserver’s control). At the end of the out-of-band verification process, each device will send a homeserver-controlled cryptographic identity to the other device. They do this by assigning the target device a device identifier that is also a cryptographic identity, exploiting a lack of domain separation between the two. When a device receives such a message, it is interpreted as a cryptographic identity. The receiving device will then sign (and thus verify) a homeserver-controlled cryptographic identity, with the false understanding that they have verified this identity out-of-band!

With that, the attacker can perform a mallory-in-the-middle attack that breaks the confidentiality and authenticity of an underlying “Olm” channel, which under the Matrix design is the protocol for transmitting end-to-end data sent between two chat partners.

A fourth attack provides for what the researchers call “semi-trusted impersonation.” At times—such as when a user adds a new device to their account—a Matrix device may not have access to inbound messages in so-called Megolm sessions, as they’re known in the Matrix specification. This can prevent the device from being able to decrypt messages sent before it was added. The device can recover by using a key request to obtain the needed decryption keys.

Matrix, the researchers said, doesn’t provide a cryptographic mechanism for ensuring that the keys shared through the key request are legitimate. Instead, the Matrix specification requires sharing of inbound messages to be completed only between devices that trust each other. When this occurs, Matrix generates a warning message to messages that were decrypted using a forwarded key.

The researchers continued:

Whilst Element clients restrict who they share keys with, no verification is implemented on who to accept key shares from. Our attack exploits this lack of verification in order to send attacker-controlled Megolm sessions to a target device, claiming they belong to a session of the device they wish to impersonate. The attacker can then send messages to the target device using these sessions, which will authenticate the messages as coming from the device being impersonated. Whilst these messages will be accompanied by a warning, this is the same warning that accompanies keys *honestly* forwarded with the “Key Request protocol.”

The fifth and sixth attacks are what the researchers call trusted impersonation and impersonation to confidentiality break. Each builds off the other to enable a server to impersonate users and read their messages. A seventh attack works against a backup feature and is only of theoretical interest because the researchers can’t instantiate an attack exploiting it against a real Matrix server.

Agreeing to Disagree

In his email, Hodgson said Matrix regards only three of the vulnerabilities—the trusted impersonation, the attack on key verification, and the malicious backup attack—as critical security issues. And even then, he said all three are flaws in how Matrix was implemented in its first-generation client software developer kit, known as matrix-js-sdk. He added:

They have highlighted two issues with the protocol which are much lower severity: that homeservers can currently add malicious users and devices to conversations that they are hosting, and that homeservers can fake history which users did not directly receive at the time. However, users are clearly warned when these situations occur: if you have verified the users in a conversation and an unverified user or device is added to a conversation, it is very clearly marked in all Matrix clients with a big red warning cross. Similarly, if an unexpected user suddenly appears in a conversation, everyone in the room is immediately informed that this user has joined, and can take appropriate evasive action.

By confusing the legitimate implementation bugs which only affect matrix-js-sdk and derivatives with these lower severity protocol design considerations, the researchers have artificially inflated the overall severity of the problem, by falsely implying that the protocol itself is vulnerable.

This said, we are also addressing these protocol design issues—we’ve already eliminated most situations where the server could fake history in tomorrow’s release, and we’ll be following up with an update which cryptographically ensures that users/devices can only be added to a room if they were invited by an admin in the room. We are also shifting to “trust on first use,” so that any unexpected devices/users get flagged, whether or not you’ve verified the users in a room.

Besides disagreeing on some of the specific vulnerabilities, the researchers and Hodgson remain at odds on another point. The researchers said the vulnerabilities they uncovered “highlight a lack of a unified and formal approach to security guarantees in Matrix” and that the specification has grown “organically with new sub-protocols adding new functionalities and thus inadvertently subverting the security guarantees of the core protocol.”

For his part, Hodgson said:

We consider the protocol itself to be sound, and we consider our security processes to be robust. We agree that the first generation implementations have grown organically (they predated the formal protocol specification), and the fact is that we have been focusing our efforts on auditing our next generation implementations which we will be switching over to in the coming months. We have 4 independent public audits booked in with Least Authority, one of which is already published: https://matrix.org/blog/2022/05/16/independent-public-audit-of-vodozemac-a-native-rust-reference-implementation-of-matrix-end-to-end-encryption, and it’s worth reiterating that the next gen implementations were not susceptable[sic] to these attacks. It’s obviously unfortunate that we didn’t catch the first gen SDK vulns in an existing audit (the bugs occurred since our original 2016 NCC Group audit), but going forwards our reference implementations will all be independently verified. Unfortunately we didn’t have resources to audit both the legacy and next-gen implementations recently, and so focused on the next-gen [implementations], knowing they will shortly obsolete the legacy [implementations].

The research paper, Practically-exploitable Cryptographic Vulnerabilities in Matrix, was authored by Martin R. Albrecht, Sofía Celi, Benjamin Dowling, and Daniel Jones. Albrecht and Jones are with the Information Security Group at the Royal Holloway University of London; Celi is with Brave Software; and Dowling is with the Security of Advanced Systems Group, University of Sheffield.

Putting It All Together

The researchers and Hodgson disagree on some key points, but there’s an important consensus that has led to changes that once again restore the confidentiality and authentication guarantees of Matrix, even in the case of a malicious or compromised homeserver. But for users to avail themselves of these assurances, the researchers said:

Each user must enable “cross-signing” and perform out-of-band verification with each of their own devices, and with each user they interact with. They must then remain vigilant: any warning messages or icons must be spotted and investigated. In the Element user interface, this requires checking the room icon and each individual message they receive (in some cases, past messages can retroactively receive a warning). Note that such warnings could be expected behavior (for example if the message was decrypted using a server-side Megolm backup or through the “Key Request protocol”). Users would need the expertise to investigate these warnings thoroughly and, if an issue is found, recover from it. If you follow these instructions without fail, Matrix can provide you with confidentiality and authentication.

This places an unnecessary burden on users of Matrix clients, limits the user base to those with an understanding of the cryptography used in Matrix and how it is applied, and is impractical for daily use. The burden this places on users is unnecessary and the result of the design flaws we highlight in our paper (this is our “Simple confidentiality break”/“Homeserver Control of Room Membership” attack). Whilst this issue will persist after today’s fixes, a remediation is planned by the Matrix developers for a later date. It is understandable that they have delayed the release of this remediation, since it requires sizable changes to the protocol.

Besides updating Element, people will also want to install patches for Beeper, Cinny, SchildiChat, Circuli, Synod.im, and any other clients based on matrix-js-sdk, matrix-ios-sdk, or matrix-android-sdk2. It’s important to install the fixes first and only then perform the verification with new devices.

This story originally appeared on Ars Technica.

Update 9-29-22, 4:30 pm ET: Updated to clarify that the patch has already been released.