Serious vulnerabilities in Matrix’s end-to-end encryption are being patched
arstechnica.com
arstechnica.com
A specific client js library implementation used in Element could have been exploited to impersonate users, join rooms, recieve future messages in these rooms.
Of course, everyone sees notifications and warning icons of these new sessions.
Responsible disclosure occurred, flaws being patched appropriately, not found used in the wild, carry on...
I applaud Matrix and Element teams for tackling the hard problems of e2e for the masses and doing a phenomenal job.
In a room where participants are verified with each other, you'd be warned of this with a loud red shield with an exclamation mark in the room header. Additionally, if you're extra worried about a room, there's a "Never send encrypted messages to unverified sessions in this room from this session" setting you can flip in the Element clients.
That said, this can and will be improved in the future, by signing room state events and implementing TOFU (trust-on-first-use) for user identities, so that you can have a large amount of protection even before you perform manual verification with other users.
Really? Are you sure there would be this banner in the case of a malicious device being added to an existing user in the room rather than a malicious user?
> While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable. However, such a detection requires careful manual membership list inspection from users and to participants, this event appears as a legitimate group membership event. In particular, in sufficiently big rooms such an event is likely to go unnoticed by users.
It's weird that we're even discussing this. In Matrix, group membership is key distribution, and it's controlled by the server! That's not OK!
> 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.
On the viability of the discussed countermeasure:
> While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable. However, such a detection requires careful manual membership list inspection from users and to participants, this event appears as a legitimate group membership event. In particular, in sufficiently big rooms such an event is likely to go unnoticed by users.
> Does this mean that Matrix does not provide confidentiality and/or authentication?
> Matrix and its implementations can, after today’s fixes, provide confidentiality and authentication assurances against malicious homeservers, if users act as follows. 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.2 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 behaviour (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 used therein, 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 work (this is our “Simple confidentiality break” attack). Whilst this issue will persist after today’s fixes, a remediation is planned by the Matrix developers for a later date.
> Some of our other attacks against Matrix’s flagship client Element are based on implementation flaws and, thus, were able to break its confidentiality and authentication guarantees even when the steps above were followed (prior to today’s patches). As of today, most of these issues should be fixed (see above), but we have not independently verified this. The Matrix developers report that other clients are not affected but, similarly, we have not independently verified this.
The bug is that you're owned, not that you didn't get an alert saying that you're owned.
This risk will be removed completely once TOFU and signed control events are implemented, which is planned (and was planned before this research). It's just more work than could fit in the disclosure timeline, especially because it's a large change needing ecosystem coordination.
This is the fundamental task of any secure group messenger. It has really one job: don't let unauthorized people read messages for the group. Here, Matrix has apparently accepted the risk that their group messenger can't do that job if the server is compromised. If you know where to look and your group is small enough, you can constantly watch to see if your homeserver has decided to stop protecting your group, but either way: your homeserver can spontaneously decide to stop protecting your group. Matrix, you had one job!
At the point where you accept this risk, you might as well just use Slack.
I genuinely do not understand the impulse people have to rationalize stuff like this. This is a devastating research result. It might be the most damaging paper ever published on a secure messaging system; I'd have to think about that.
So yes: we should switch to client-controlled membership management, and we've already started the work to do so. However, the Matrix spec and its implementations has always been transparent that it's up to the user to verify the membership of the room - for after all, if they don't bother verifying users, then all bets will always be off anyway. For instance https://element.io/blog/e2e-encryption-by-default-cross-sign... explicitly says: "You’ve verified this user, but they have risky unverified sessions logged in! A room containing any red users is shown as red." I'm not sure this exactly counts as a research result, let alone a devastating one.
However, totally agreed that we can improve on this, and we're on the case.
This is how things are supposed to work. Protocol and implementations are open source so people can inspect what they do and point out problems and get them fixed.
This finally means that researchers are paying attention to the Matrix protocol. This makes me more confident in the Matrix stuff rather than less.