Headline
CVE-2022-39257: Upgrade now to address E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2 | Matrix.org
Matrix iOS SDK allows developers to build iOS apps compatible with Matrix. Prior to version 0.23.19, an attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the matrix-ios-sdk implementing a too permissive key forwarding strategy. The default policy for accepting key forwards has been made more strict in the matrix-ios-sdk version 0.23.19. matrix-ios-sdk will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. The SDK now sets a trusted flag on the decrypted message upon decryption, based on whether the key used to decrypt the message was received from a trusted source. Clients need to ensure that messages decrypted with a key with trusted = false are decorated appropriately (for example, by showing a warning for such messages). This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.
TL;DR:
- Two critical severity vulnerabilities in end-to-end encryption were found in the SDKs which power Element, Beeper, Cinny, SchildiChat, Circuli, Synod.im and any other clients based on matrix-js-sdk, matrix-ios-sdk or matrix-android-sdk2.
- These have now been fixed, and we have not seen evidence of them being exploited in the wild. All of the critical vulnerabilities require cooperation from a malicious homeserver to be exploited.
- Please upgrade immediately in order to be protected against these vulnerabilities.
- Clients with other encryption implementations (including Hydrogen, ElementX, Nheko, FluffyChat, Syphon, Timmy, Gomuks and Pantalaimon) are not affected; this is not a protocol bug.
- We take the security of our end-to-end encryption extremely seriously, and we have an ongoing series of public independent audits booked to help guard against future vulnerabilities. We will also be making some protocol changes in the future to provide additional layers of protection.
- This resolves the pre-disclosure issued on September 23rd.
Hi all,
Recently we have been hard at work investigating some subtle security vulnerabilities in certain implementations of Matrix’s end-to-end encryption which were responsibly disclosed to us by researchers at Royal Holloway University London, University of Sheffield and Brave Software. Two of these vulnerabilities are critical severity, in that they could allow malicious server admins to attack their users, and are implementation bugs in clients using matrix-js-sdk (e.g. Element Web) or implementations derived from matrix-js-sdk, rather than protocol flaws. matrix-rust-sdk (and other 2nd/3rd generation SDKs) are not affected by these. These vulnerabilities are fixed in today’s release, and we are not aware of them having been exploited in the wild.
If you’re using Element or an application that shares the same SDKs (Beeper, Cinny, SchildiChat, Circuli, Synod.im) then please upgrade now. Do not perform verification with new devices until you have upgraded.
We’d like to thank the security researchers for investing significant time and effort into doing a deep dive to find these issues, and thus contributing materially to making Matrix more secure for the whole ecosystem. Despite our best efforts, there is always a risk of security issues in software, and we’re very glad to have identified and fixed these issues while also taking the opportunity to improve our vulnerability disclosure and coordinated upgrade process.
Please note that the critical severity issues are implementation issues in matrix-js-sdk and derivatives, and are not protocol issues in Matrix. The latest version of the researchers’ paper that we’ve seen incorrectly presents Element as 'the reference Matrix client’, and confuses the higher severity implementation bugs with lower severity protocol critique. This is very unfortunate, given Hydrogen, ElementX, Nheko, FluffyChat, Syphon, Timmy, Gomuks and Pantalaimon and other independent implementations are not affected. In fact, every client independently implemented using the Matrix spec seems to have got it right, which speaks well of the protocol. It’s only the first generation SDK (predating the spec) and its derivatives which had these bugs.
The two critical severity issues lead to three attack scenarios, all of which are prevented by today’s releases:
"Key/Device Identifier Confusion in SAS Verification" – A bug existed in matrix-js-sdk where it confused together device IDs and cross-signing keys (given under the hood, cross-signing keys are represented as devices). 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 being verified. This bug is only present in matrix-js-sdk (not iOS or Android SDKs), tracked as a critical severity CVE: CVE-2022-39250.
"Trusted Impersonation" – matrix-js-sdk (and derived SDKs) suffered from a protocol-confusion bug where it would incorrectly accept to-device messages encrypted by Megolm rather than Olm, attributing them to the Megolm sender rather than the actual sender. As a result, an attacker could fake the trusted sender of to-device messages, allowing them to send fake to-device messages to devices - e.g. fake keys to spoof historical messages from other users. This bug is tracked as a critical severity CVE: CVE-2022-39251 (matrix-js-sdk), CVE-2022-39255 (matrix-ios-sdk) and CVE-2022-39248 (matrix-android-sdk2).
"Malicious key backup" – the above ‘trusted impersonation’ bug in matrix-js-sdk (and derived SDKs) could be used by a malicious homeserver admin to add a malicious key backup to the user’s account under certain unusual conditions in order to exfiltrate message keys. While we are not aware of this being exploited in the wild, out of an abundance of caution we recommend checking your key backup settings. If you are particularly paranoid you may wish to reset your online key backup. This doesn’t have a separate CVE, as the root cause is the same as "Trusted Impersonation".
Three lower priority issues were also identified by the researchers:
"Semi-trusted Impersonation" – matrix-js-sdk (and derived SDKs) accepted keys forwarded by other users, even if your client didn’t request them. As a result, a malicious server admin could fake an encrypted message to look as if it was sent from a given user on that server. However, impersonated messages like this are clearly marked by clients like Element with a clear “The authenticity of this encrypted message can’t be guaranteed” warning – which is why we consider this low severity. That said, it’s an avoidable attack, and we’ve fixed this by ensuring that clients don’t accept ‘unsafe’ keys (with the exception of keys forwarded when you invite a user to an existing conversation). In future, in Olm/Megolm v2 we’re also linking key-sending events to the underlying recipient Olm identity to ensure that keys cannot be misappropriated. This issue is tracked as a moderate severity CVE: CVE-2022-39249 (matrix-js-sdk), CVE-2022-39257 (matrix-ios-sdk) and CVE-2022-39246 (matrix-android-sdk2).
"Homeserver Control of Room Membership" – A malicious homeserver can fake invites on behalf of its users to invite malicious users into their conversations, or add malicious devices into its users accounts. However, when this happens, we clearly warn the user: if you have verified the users you are talking to, the room and user will be shown with a big red cross to mark if malicious devices have been added. Similarly, if an unexpected user is invited to a conversation, all users can clearly see and take evasive action. Therefore we consider this a low severity issue. That said, this behaviour can be improved, and we’ve started work on switching our trust model to trust-on-first-use (so that new untrusted devices are proactively excluded from conversations, even if you haven’t explicitly verified their owner) - and we’re also looking to add cryptographic signatures to membership events in E2EE rooms to stop impersonated invites. These fixes will land over the coming months.
"IND-CCA break" – Matrix’s usage of AES-CTR to encrypt attachments, secrets and symmetric key backups is not "IND-CCA2 secure", because it does not include the AES initialisation vector within the hash used to secure the payload from tampering. As a result, if an attacker could observe the result of both a given encryption and a given decryption operation, it would be possible to extract the encryption private key. However, this is a purely theoretical attack as Matrix does not provide a way to mount the attack. In the future, we will fix our use of AES-CTR to include the IV within the hash.
We’d like to again thank Martin R. Albrecht and Dan Jones from the Information Security Group at Royal Holloway University London, Benjamin Dowling from Security of Advanced Systems Group, University of Sheffield and Sofía Celi from Brave Software for discovering these issues and responsibly disclosing them to us, and then working with us to agree on an extended disclosure window given the amount of work needed to verify and ship fixes throughout Matrix over the course of the summer period. We welcome any further formal security analysis work, and hope that it will distinguish clearly between Matrix-the-protocol and Matrix implementations like matrix-js-sdk, rather than conflating them. You can read their full paper here.
We’d also like to thank all the downstream Element package maintainers, downstream forks and other affected clients for working together under time constraints for this coordinated release - your patience and understanding is very much appreciated indeed.
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.
We started the process of auditing matrix-rust-sdk with the Least Authority vodozemac audit in May, and we have three more audits agreed – covering matrix-rust-sdk-crypto, matrix-rust-sdk, and a whole reference Matrix stack. Ironically, the mitigation work for these vulnerabilities in the legacy SDKs has severely impacted our timelines for finishing matrix-rust-sdk-crypto work (in fact, we had to push back the Least Authority audit of matrix-rust-sdk-crypto given the burndown has not progressed), but we will be shifting to the new audited codebase as rapidly as we possibly can.
Over the coming months we will also introduce our first ever major version update of Olm and Megolm, in order to fix the MAC truncation issue highlighted in the vodozemac audit (Issue J), and reduce the risk of further key-forwarding issues (as per the “Semi-trusted Impersonation” vulnerability above). New conversations will default to using v2 of Olm/Megolm for security, and existing conversations can be optionally upgraded (similar to a ‘room version’ upgrade in Matrix today). We are also adding extensive end-to-end testing using Polyjuice and Traffic Light to stress-test encryption and improve reliability.
Finally, we will continue our research into layering Matrix over Messaging Layer Security (MLS) - the IETF proposed standard for interoperable end-to-end encrypted group messaging. This work has been delayed by the mitigation activity above, but otherwise it’s making good progress and we’re excited to see how Decentralised MLS performs in reality against Olm+Megolm v2.
We’d like to apologise to the wider Matrix community for the inconvenience and disruption of these issues, and thank you for your patience while we’ve resolved them.
Matthew, Denis and the Matrix cryptography & security teams.
Related news
Ubuntu Security Notice 5724-1 - Multiple security issues were discovered in Thunderbird. If a user were tricked into opening a specially crafted website in a browsing context, an attacker could potentially exploit these to cause a denial of service, bypass Content Security Policy or other security restrictions, or execute arbitrary code. These issues only affect Ubuntu 18.04 LTS, Ubuntu 20.04 LTS and Ubuntu 22.04 LTS.
Gentoo Linux Security Advisory 202210-35 - Multiple vulnerabilities have been found in Mozilla Thunderbird, the worst of which could result in arbitrary code execution. Versions less than 102.4.0 are affected.
Red Hat Security Advisory 2022-7184-01 - Mozilla Thunderbird is a standalone mail and newsgroup client. This update upgrades Thunderbird to version 102.4.0. Issues addressed include a denial of service vulnerability.
Red Hat Security Advisory 2022-7183-01 - Mozilla Thunderbird is a standalone mail and newsgroup client. This update upgrades Thunderbird to version 102.4.0. Issues addressed include a denial of service vulnerability.
Red Hat Security Advisory 2022-7181-01 - Mozilla Thunderbird is a standalone mail and newsgroup client. This update upgrades Thunderbird to version 102.4.0. Issues addressed include a denial of service vulnerability.
Red Hat Security Advisory 2022-7178-01 - Mozilla Thunderbird is a standalone mail and newsgroup client. This update upgrades Thunderbird to version 102.4.0. Issues addressed include a denial of service vulnerability.
Red Hat Security Advisory 2022-7190-01 - Mozilla Thunderbird is a standalone mail and newsgroup client. This update upgrades Thunderbird to version 102.4.0. Issues addressed include a denial of service vulnerability.
Red Hat Security Advisory 2022-7182-01 - Mozilla Thunderbird is a standalone mail and newsgroup client. This update upgrades Thunderbird to version 102.4.0. Issues addressed include a denial of service vulnerability.
An update for thunderbird is now available for Red Hat Enterprise Linux 8. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-39236: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a data corruption issue * CVE-2022-39249: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to an impersonation attack by malicious server administrators * CVE-2022-39250: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a device verification attack * CVE-2022-39251: ...
An update for thunderbird is now available for Red Hat Enterprise Linux 7. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-39236: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a data corruption issue * CVE-2022-39249: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to an impersonation attack by malicious server administrators * CVE-2022-39250: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a device verification attack * CVE-2022-39251: ...
An update for thunderbird is now available for Red Hat Enterprise Linux 8.4 Extended Update Support. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-39236: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a data corruption issue * CVE-2022-39249: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to an impersonation attack by malicious server administrators * CVE-2022-39250: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a device verification...
An update for thunderbird is now available for Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-39236: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a data corruption issue * CVE-2022-39249: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to an impersonation attack by malicious server administrators * CVE-2022-39250: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a device ve...
An update for thunderbird is now available for Red Hat Enterprise Linux 8.2 Extended Update Support. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-39236: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a data corruption issue * CVE-2022-39249: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to an impersonation attack by malicious server administrators * CVE-2022-39250: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a device verification...
An update for thunderbird is now available for Red Hat Enterprise Linux 9. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-39236: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a data corruption issue * CVE-2022-39249: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to an impersonation attack by malicious server administrators * CVE-2022-39250: Mozilla: Matrix SDK bundled with Thunderbird vulnerable to a device verification attack * CVE-2022-39251: ...
Confidentiality and authentication flaws uncovered by researchers
## Impact An attacker cooperating with a malicious homeserver could interfere with the verification flow between two users, injecting its own cross-signing user identity in place of one of the users’ identities, leading to the other device trusting/verifying the user identity under the control of the homeserver instead of the intended one. The vulnerability is a bug in the matrix-js-sdk, caused by checking and signing user identities and devices in two separate steps, and inadequately fixing the keys to be signed between those steps. Even though the attack is partly made possible due to the design decision of treating cross-signing user identities as Matrix devices on the server side (with their device ID set to the public part of the user identity key), no other examined implementations were vulnerable. ## Patches The matrix-js-sdk has been modified to double check that the key signed is the one that was verified instead of just referencing the key by ID. An additional check has ...
### Impact An attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield. Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device. These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm. ### Patches matrix-android-sdk2 has been modified to only accept Olm-encrypted to-device messages a...
### Impact An attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the matrix-android-sdk2 implementing a too permissive [key forwarding](https://spec.matrix.org/v1.3/client-server-api/#key-requests) strategy on the receiving end. Key forwarding is a mechanism allowing clients to recover from “unable to decrypt” messages when they missed the initial key distribution, at the time the message was originally sent. Examples include accessing message history before they joined the room but also when some network/federation errors have occurred. ### Patches The default policy for accepting key forwards has been made more strict in the matrix-android-sdk2. The matrix-android-sdk2 will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. A ...
### Impact An attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield. Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm. ### Patches matrix-js-sdk has been modified to only accept Olm-encrypted to-device messages. Out of caution, several other checks have been audited or added: - Cleartext `m.room_key`, `m.forwarded_room_key` and `m.secret.send` to_device messages are discarded. - S...
## Impact An attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the matrix-js-sdk implementing a too permissive [key forwarding](https://spec.matrix.org/v1.3/client-server-api/#key-requests) strategy on the receiving end. Key forwarding is a mechanism allowing clients to recover from “unable to decrypt” messages when they missed the initial key distribution, at the time the message was originally sent. Examples include accessing message history before they joined the room but also when some network/federation errors have occurred. ## Patches The default policy for accepting key forwards has been made more strict in the matrix-js-sdk. matrix-js-sdk will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. A unique exception to thi...
matrix-android-sdk2 is the Matrix SDK for Android. Prior to version 1.5.1, an attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield. Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device. These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm. matrix-android-sdk2 version 1.5.1 has be...