Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Using the `IdentityBasedStrategy` setting when calling `Device::encrypt_event_raw` or `OlmMachine::encrypt_content_for_devices` may cause a panic if the recipient does not have cross-signing keys.
Recommended action: Upgrade to 0.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The matrix-sdk-crypto crate before 0.16.1 is missing a check for the sender's user ID when decrypting an Olm-encrypted to-device message containing the senderdevicekeys property. This could be exploited to spoof the sender of an encrypted to-device message, but only if the attacker colludes with (or is) the homeserver operator. Patches This issue is fixed in matrix-sdk-crypto 0.16.1. Workarounds There are no known workarounds for the issue. References This issue was fixed in https://github.com/matrix-org/matrix-rust-sdk/pull/6553. For more information If you have any questions or comments about this advisory, please email us at security at matrix.org.
Recommended action: Upgrade to 0.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
matrix-sdk-crypto since version 0.8.0 up to 0.11.0 does not correctly validate the sender of an encrypted event. Accordingly, a malicious homeserver operator can modify events served to clients, making those events appear to the recipient as if they were sent by another user. Although the CVSS score is 4.9 (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N), we consider this a High Severity security issue. Details The Matrix specification requires that clients ensure that "the event’s sender, roomid, and the recorded sessionid match a trusted session". The vulnerable matrix-sdk-crypto versions check that the roomid matches that of the session denoted by sessionid, but do not check the sender. Patches The issue is resolved by 13c1d20, included in versions 0.11.1 and 0.12.0 of matrix-sdk-crypto. Workarounds Since a successful attack requires administrator access to the homeserver, users who trust the administrators of their local homeserver are not affected. References…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Versions of the matrix-sdk-crypto Rust crate before 0.8.0 lack a dedicated mechanism to notify that a user's cryptographic identity has changed from a verified to an unverified one, which could cause client applications relying on the SDK to overlook such changes. Patches matrix-sdk-crypto 0.8.0 adds a new VerificationLevel::VerificationViolation enum variant which indicates that a previously verified identity has been changed. References - Patch: https://github.com/matrix-org/matrix-rust-sdk/pull/3795
Recommended action: Upgrade to 0.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The UserIdentity::isverified() method in the matrix-sdk-crypto crate before version 0.7.2 doesn't take into account the verification status of the user's own identity while performing the check and may as a result return a value contrary to what is implied by its name and documentation. Impact If the method is used to decide whether to perform sensitive operations towards a user identity, a malicious homeserver could manipulate the outcome in order to make the identity appear trusted. This is not a typical usage of the method, which lowers the impact. The method itself is not used inside the matrix-sdk-crypto crate. Patches The 0.7.2 release of the matrix-sdk-crypto crate includes a fix. Workarounds None.
Recommended action: Upgrade to 0.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Introduction In Matrix, the server-side key backup stores encrypted copies of Matrix message keys. This facilitates key sharing between a user's devices and provides a redundant copy in case all devices are lost. The key backup uses asymmetric cryptography, with each server-side key backup assigned a unique public-private key pair. Impact Due to a logic bug introduced in https://github.com/matrix-org/matrix-rust-sdk/pull/2961/commits/71136e44c03c79f80d6d1a2446673bc4d53a2067, the matrix-sdk-crypto crate version 0.7.0 will sometimes log the private part of the backup key pair to Rust debug logs (using the tracing crate). Patches This issue has been resolved in matrix-sdk-crypto version 0.7.1. Workarounds None. References - crates.io release For more information If you have any questions or comments about this advisory, please email us at security at matrix.org.
Recommended action: Upgrade to 0.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When matrix-rust-sdk before 0.6 requests a room key from our devices, it correctly accepts key forwards only if they are a response to a previous request. However, it doesn't check that the device that responded matches the device the key was requested from. This allows a malicious homeserver to insert room keys of questionable validity into the key store in some situations, potentially assisting in an impersonation attack. Note that even if key injection succeeds in this way, all forwarded keys have the imported flag set, which is used as an indicator that such keys have lesser authentication properties (and should be marked as such in clients, e.g. with a grey shield besides the message). For more information If you have any questions or comments about this advisory, e-mail us at security@matrix.org.
Recommended action: Upgrade to 0.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.