The Matrix.org Foundation, which oversees the Matrix decentralized communications protocol, said Monday that several Matrix clients and libraries contain a vulnerability that can potentially be exploited to expose encrypted messages.
The organization said an error in the implementation of the Matrix key-sharing system – designed to allow a user’s newly connected device to obtain the keys to decrypt old messages – led to the creating client code that fails to adequately verify the identity of the device. Therefore, an attacker could recover a Matrix client user’s keys.
Specifically, a paragraph from the Matrix E2EE (End-to-End Encryption) Implementation Guide, which described the desired key management routine, was followed when creating the original version of Matrix.
matrix-js-sdk coded. According to the foundation, this SDK “did not sufficiently verify the identity of the device requesting the key share”, and this oversight has made its way into other Matrix chat libraries and clients.
“This is not a protocol or specification bug, but an implementation bug that has unfortunately subsequently been reproduced in other independent implementations,” the foundation insisted.
To exploit this vulnerability, an attacker would need to gain access to the message recipient’s account, either through stolen credentials or by compromising the victim’s home server.
“Thus, the greatest risk is to users who are in encrypted rooms containing malicious servers,” the Matrix.org Foundation said in a statement. blog post. “Malicious server administrators could attempt to impersonate their users’ devices in order to spy on messages sent by vulnerable clients in this room.”
Malicious server administrators could attempt to impersonate their users’ devices in order to spy on messages sent by vulnerable clients in this room
For the moment, this risk remains theoretical because the foundation has declared that it has not seen this flaw being exploited in the wild. Affected clients and libraries include: Element (Web/Desktop/Android, but not iOS), FluffyChat, Nheko, Cinnyand SchildiChat.
A handful of other applications that have not implemented key sharing are not considered vulnerable. These include: Chatty, Hydrogen, matrix, purple-matrix and Siphon.
of the matrix key sharing system was added in 2016 to allow a Matrix client application to request the message recipient’s other devices or the sender’s originating device for the keys to decrypt past messages. It also allowed a user to log into a new client and access chat history when devices with the necessary keys were offline or the user had not backed up the keys.
The recommended implementation, as supported
matrix-js-sdkinvolved automatically sharing keys only with verified devices of the same user.
“Unfortunately, the implementation did not sufficiently verify the identity of the device requesting the key sharing, meaning that a compromised account could impersonate the device requesting the keys, creating this vulnerability” , explained the Matrix.org Foundation.
Patches for the affected software have been made available in the affected repositories. The foundation said it intends to review the key sharing documentation and revise it to clarify how to implement key sharing in a secure manner. The group also said it will reconsider 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 that other libraries don’t have to reimplement logic that has proven difficult to do correctly.
“This will have the effect of reducing the attack surface and simplifying audits for software that chooses to use
matrix-rust-sdk“said the foundation. ®