Matrix chat encryption sunk by five now-patched holes Four security researchers have identified five cryptographic vulnerabilities in code libraries that can be exploited to undermine Matrix encrypted chat clients. This includes impersonating users and sending messages as them. The researchers – Martin Albrecht (University of London), Sofía Celi (Brave Software), Benjamin Dowling …
From the post that's linked haflway through the article:
>Clients with other encryption implementations (including Hydrogen, ElementX, Nheko, FluffyChat, Syphon, Timmy, Gomuks and Pantalaimon) are not affected; this is not a protocol bug.
>Meanwhile, we are taking extreme measures to avoid future E2EE vulnerabilities. You will notice that matrix-rust-sdk, hydrogen-sdk and other 2nd and 3rd generation SDKs were not affected by the bugs at the root cause of the critical issues here. This is precisely why we have been working on replacing the first generation SDKs with a clean, carefully written Rust implementation in the form of matrix-rust-sdk, complete with an ongoing independent public audit.
Just think it's worth pointing out clearly as the article mixes past problems and comments from the researchers in such a way that it seems to imply that the protocol itself is to blame rather than the implementation in these older libraries used by some of the clients.
It's pretty clear, right off the bat, this is a code-level issue, with patches for vulnerable apps rather than changes to the protocol.
Yes, the protocol is mentioned, in that, a study of a protocol may not only uncover shortcomings in the protocol design but also may indicate where there will likely be problems in implementations [triv.]
Don't forget to use corrections@theregister.com if you think you've spotted something wrong, please.
C.
We, the research team, were pretty clear that these were both implementation and protocol issues:
"""
Are these attacks design flaws in the Matrix specification?
We will explain this one by one by using the name of the attacks previously defined:
a. Simple confidentiality break: The root cause of this attack is the fact that room management messages are not authenticated, which is a design flaw in the protocol itself, as no mechanism was specified for authentication of such messages.
b. Attack against out-of-band verification: This attack exploits an insecure implementation choice enabled by a design flaw in the specification as there is no domain separation enforced there.
c. Semi-trusted impersonation: This is mostly implementation bug supported by a lack of guidance on the processing of incoming key shares in spec.
d. Trusted impersonation: This is an implementation error as no check is performed to check whether Olm is used for encryption or not.
e. Impersonation to confidentiality break: This is an implementation error as no check is performed to check whether Olm is used for encryption or not.
f. IND-CCA break: This theoretical attack exploits a protocol design flaw.
"""
https://nebuchadnezzar-megolm.github.io/
Well alright, beat a dead horse a little more. XMPP is to Matrix what a floppy disk is to a SSD. The base spec did not even include E2E and when the extension was created, it had serious limitations such as a pain in the arse key management (and iirc no E2E group chat). In the end XMPP turned into a ZIP disk, but it'll never be a SSD.
> The base spec did not even include E2E and
I'm sorry, what part of *extensible* messaging and presence protocol did you fail to understand?
End to end encryption wasn't even a thing in 1999 when the protocol was created. The fact that it does do it is a testimony to its robust design.
I have nothing against matrix per se, but it does not bring anything new into the game. They could have used the existing XMPP infrastructure if they wanted but they chose not to, probably for commercial reasons.
What the Matrix people are trying to do is admirable, but the large functionality needed to do that runs afoul of the K.I.S.S. principle, and the resulting complexity is a breeding ground for bugs.
I think we need better ways to analyze the integration of comp!ex subcomponents, but some CompSci B.S./M.S./Ph.D-holder may have more knowledge of this.
The hardest part is secure group membership - for that purpose hub and spoke, with a single authority, is the least vulnerable alternative. It's conceptually simple to extend a 1-to-1 talk to N times 1-to-1. Of course the hub might go down - that's the downside - but in the interests of security that might be a good time to shut up.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
