Confidentiality and authentication flaws uncovered by researchers
Matrix has patched five serious vulnerabilities in its end-to-end encryption that break the confidentiality and authentication of messages.
The flaws would allow a malicious server to read user messages and impersonate devices.
Matrix currently has 69 million accounts in total, spread over around 100,000 servers. The technology provides a federated communication protocol, allowing clients with accounts on different Matrix servers – their homeservers – to exchange messages across the entire ecosystem.
The platform enables end-to-end encryption by default.
However, four researchers – Martin Albrecht of the Royal Holloway, University of London, Sofía Celi of Brave Software, Benjamin Dowling of the University of Sheffield, and Daniel Jones of the University of London – have demonstrated (PDF) five practically-exploitable flaws.
Fairly straightforward
The vulnerabilities, two of which are rated critical, undermine assurances of authentication and confidentiality normally offered by the Matrix platform.
"All our attacks require a malicious homeserver – the server where users create accounts – i.e., no external party could mount them because all Matrix communication between clients and servers and between servers for federation are protected by TLS," Albrecht told The Daily Swig.
Catch up with the latest encryption-related news and analysis
"Now, for a malicious homeserver, carrying out these attacks would have been easy. We have implemented proof-of-concept attacks for the vulnerabilities we reported, and these [are] usually fairly straightforward."
The first critical vulnerability, CVE-2022-39250, is key/device identifier confusion in SAS verification, a bug in matrix-js-sdk that confuses device IDs and cross-signing keys. “This could be exploited by a malicious server admin to break emoji-based verification when cross-signing is in use, authenticating themselves rather than the target user,” according to a security notice by the developers of Matrix.
The other critically-rate flaw, CVE-2022-39251, is a protocol-confusion bug that incorrectly accepts to-device messages encrypted by Megolm rather than Olm, attributing them to the Megolm sender rather than the actual sender. The vulnerability potentially allows an attacker to send fake keys in order to spoof historical messages from other users.
In addition, the flaw creates a means to add a malicious key backup to a user’s account in order to exfiltrate message keys. Matrix’s developers said this attack scenario, which would require certain unusual preconditions, has not been detected in the wild.
Impersonation attack
Meanwhile, a semi-trusted impersonation attack exploits a lack of verification in Element in order to send attacker-controlled Megolm sessions to a target device, falsely posing as a session of the device they wish to impersonate.
Another vulnerability allows a malicious homeserver to add users under their control to end-to-end encrypted rooms – where they can then decrypt future messages sent in the room. This happens because room management messages aren’t authenticated in the Matrix specification, meaning they can be faked by a rogue homeserver.
Lastly Matrix’s use of AES-CTR to encrypt attachments, secrets, and symmetric key backups was faulted for lacking cryptographical rigour. Not good but, as the researchers acknowledge, this IND-CCA break falls short of anything that would result in a practical attack.
The researchers conclude that some of the vulnerabilities reside in the Matrix protocol itself, saying that they highlight the need for a systematic and formal analysis of the cryptography in the Matrix standard.
Enter the Matrix
However, the developers of Matrix dispute this.
"We consider the protocol itself to be sound and our security processes to be robust," Matthew Hodgson, co-founder and project lead for Matrix and CEO/CTO at Element, told The Daily Swig.
"For instance, we’re currently in the middle of a series of public, independent audits of our next-gen SDKs [software development kits] from Least Authority, and it’s worth noting that our next-gen implementations are not vulnerable to the implementation bugs in question here."
Albrecht responded: "The Matrix developers have shared with us their plans for addressing the issues we argued about, so we are hopeful that eventually the right outcome – Matrix achieving the security guarantees that it promises – will be achieved."
Element offers the flagship client and prototype implementation of Matrix.
RELATED Let’s Encrypt builds infrastructure to support browser-based certificate revocation revival
