The Matrix.org Foundation, which oversees the Matrix decentralized communication protocol, said on Monday multiple Matrix clients and libraries contain a vulnerability that can potentially be abused to expose encrypted messages.
The organization said a blunder in an implementation of the Matrix key sharing scheme – designed to allow a user's newly logged-in device to obtain the keys to decrypt old messages – led to the creation of client code that fails to adequately verify device identity. As a result, an attacker could fetch a Matrix client user's keys.
Specifically, a paragraph in Matrix E2EE (end-to-end encryption) Implementation Guide, which described the desired key handling routine, was followed in the creation of Matrix's original
matrix-js-sdk code. According to the foundation, this SDK "did not sufficiently verify the identity of the device requesting the keyshare," and this oversight made its way into other libraries and Matrix chat clients.
"This is not a protocol or specification bug, but an implementation bug which was then unfortunately replicated in other independent implementations," the foundation insisted.
To exploit this vulnerability, an attacker would need to access the message recipient's account, via stolen credentials or compromising the victim's homeserver.
"Thus, the greatest risk is to users who are in encrypted rooms containing malicious servers," the Matrix.org Foundation said in a blog post. "Admins of malicious servers could attempt to impersonate their users' devices in order to spy on messages sent by vulnerable clients in that room."
Admins of malicious servers could attempt to impersonate their users' devices in order to spy on messages sent by vulnerable clients in that room
At the moment, this risk remains theoretical as the foundation said it has not seen this flaw being exploited in the wild. Among the affected clients and libraries are: Element (Web/Desktop/Android, but not iOS), FluffyChat, Nheko, Cinny, and SchildiChat.
A handful of other applications that haven't implemented key sharing are believed not to be vulnerable. These include: Chatty, Hydrogen, mautrix, purple-matrix, and Syphon.
Matrix's key-sharing scheme was added in 2016 as a way to let a Matrix client app ask a message recipient's other devices or the sender's originating device for the keys to decrypt past messages. It also served to provide a way for a user to log into a new client and gain access to chat history when devices with the necessary keys were offline or the user hadn't backed the keys up.
The recommended implementation, as taken in
matrix-js-sdk, involved sharing keys automatically only to devices of the same user that have been verified.
"Unfortunately, the implementation did not sufficiently verify the identity of the device requesting the keyshare, meaning that a compromised account can impersonate the device requesting the keys, creating this vulnerability," explained the Matrix.org Foundation.
- Slack has entered the Matrix: Element builds a bridge to realm of encrypted, decentralised comms
- Element's latest bridge for Matrix: 'All the good stuff from WhatsApp, without the less good Facebook stuff'
- Element rolls out bridge for Microsoft Teams to cross into Matrix's encrypted comms land
- What's that hurtling down the Bifröst? Node-based network fun with Yggdrasil 0.4
Patches for affected software have been made available in the relevant repositories. The foundation said it intends to review the key sharing documentation and to revise it to make it clearer how to implement key sharing in a safe way. The group also said it will revisit whether key sharing is really necessary in the Matrix protocol and will focus on making
matrix-rust-sdk a portable reference implementation of the Matrix protocol, so other libraries don't have to reimplement logic that has proven to be difficult to do properly.
"This will have the effect of reducing attack surface and simplifying audits for software which chooses to use
matrix-rust-sdk," the foundation said. ®