The olmsessiondescribe function in Matrix libolm before 3.2.7 is vulnerable to a buffer overflow. The Olm session object represents a cryptographic channel between two parties. Therefore, its state is partially controllable by the remote party of the channel. Attackers can construct a crafted sequence of messages to manipulate the state of the receiver's session in such a way that, for some buffer sizes, a buffer overflow happens on a call to olmsessiondescribe. Furthermore, safe buffer sizes were undocumented. The overflow content is partially controllable by the attacker and limited to ASCII spaces and digits. The known affected products are Element Web And SchildiChat Web.

A logic error in the room key sharing functionality of Element Android before 1.2.2 and matrix-android-sdk2 (aka Matrix SDK for Android) before 1.2.2 allows a malicious Matrix homeserver present in an encrypted room to steal room encryption keys (via crafted Matrix protocol messages) that were originally sent by affected Matrix clients participating in that room. This allows the attacker to decrypt end-to-end encrypted messages sent by affected clients.

matrix-sdk-base is the base component to build a Matrix client library. Versions 0.14.1 and prior are unable to handle responses that include custom m.room.joinrules values due to a serialization bug. This can be exploited to cause a denial-of-service condition, if a user is invited to a room with non-standard join rules, the crate's sync process will stall, preventing further processing for all rooms. This is fixed in version 0.16.0.

matrix-rust-sdk is an implementation of a Matrix client-server library in Rust, and matrix-sdk-crypto is the Matrix encryption library. Prior to version 0.6, when a user requests a room key from their devices, the software correctly remembers the request. When the user receives a forwarded room key, the software accepts it without checking who the room key came from. This allows homeservers to try to insert room keys of questionable validity, potentially mounting an impersonation attack. Version 0.6 fixes this issue.

matrix-js-sdk is a Matrix messaging protocol Client-Server SDK for JavaScript. In versions prior to 19.4.0 events sent with special strings in key places can temporarily disrupt or impede the matrix-js-sdk from functioning properly, potentially impacting the consumer's ability to process data safely. Note that the matrix-js-sdk can appear to be operating normally but be excluding or corrupting runtime data presented to the consumer. This issue has been fixed in matrix-js-sdk 19.4.0 and users are advised to upgrade. Users unable to upgrade may mitigate this issue by redacting applicable events, waiting for the sync processor to store data, and restarting the client. Alternatively, redacting the applicable events and clearing all storage will often fix most perceived issues. In some cases, no workarounds are possible.

Impact If Synapse and a malicious homeserver are both joined to the same room, the malicious homeserver can trick Synapse into accepting previously rejected events into its view of the current state of that room. This can be exploited in a way that causes all further messages and state changes sent in that room from the vulnerable homeserver to be rejected.

Synapse homeservers are affected by this issue if and only if they are joined to rooms which members of untrusted homeservers are joined or invited to.

- Synapse homeservers in rooms available over public federation are affected. - Synapse homeservers with federation disabled are not affected. - Synapse homeservers in a closed federation containing only trusted servers are not affected. - Synapse homeservers which are only joined to rooms with federation disabled[^1] are not affected.

Patches Administrators of homeservers with federation enabled are advised to upgrade to 1.68.0 or higher.

Workarounds Federation can be disabled by setting federationdomainwhitelist to an empty list ([]). from the vulnerable homeserver to be rejected. This issue has been patched in version 1.68.0

References - https://github.com/matrix-org/synapse/pull/13723

[^1]: See m.federate in the m.room.create definition.

For more information

If you have any questions or comments about this advisory, e-mail us at security@matrix.org.

Impact Synapse is an open-source Matrix homeserver written and maintained by the Matrix.org Foundation. The Matrix Federation API allows remote homeservers to request the authorisation events of events in a room. This is necessary so that a homeserver receiving some events can validate that those events are legitimate and permitted in their room. However, in versions of Synapse up to and including 1.68.0, a Synapse homeserver answering a query for authorisation events does not sufficiently check that the requesting server should be able to access them.

Authorisation events include power level events (the list of user IDs and their power levels at the time) and relevant membership events (including the display name of the sender of that event), as well as events like m.room.create, m.room.thirdpartyinvite and m.room.joinrules. Non-authorisation events are unaffected, so it isn't possible to e.g. extract message contents this way.

This issue is only exploitable when a malicious actor knows the ID of a target room and the ID of an event from that room. In most cases, this makes exploitation infeasible. This issue is of negligible consequence for public rooms given that any server can easily join the room in order to be allowed to view authorisation events. Further, deployments in a closed federation where all homeservers are trustworthy are not affected.

Patches

The issue was patched in Synapse 1.69.0. Homeserver administrators are advised to upgrade.

Workarounds

Synapse can be configured with a list of servers that it is allowed to federate with [federationdomainwhitelist]. If this list is in use and all the servers on the list are trusted not to exploit this issue, then this issue is of no consequence.

This workaround is not practical for homeservers participating in open federation as interaction with any server not on the list would have to happen indirectly through servers that are, leading to inconsistent delays in message delivery.

[federationdomainwhitelist]: https://matrix-org.github.io/synapse/v1.68/usage/configuration/configdocumentation.html#federationdomainwhitelist

References

Fixed in https://github.com/matrix-org/synapse/pull/13823.

For more information

If you have any questions or comments about this advisory, e-mail us at security@matrix.org.

Matrix JavaScript SDK is the Matrix Client-Server software development kit (SDK) for JavaScript. Prior to version 19.7.0, 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. This would lead 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. Starting with version 19.7.0, 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 been made to report an error when one of the device ID matches a cross-signing key. As this attack requires coordination between a malicious homeserver and an attacker, those who trust their homeservers do not need a particular workaround.

Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript. Prior to version 19.7.0, 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. Starting with version 19.7.0, 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. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.

Impact

URL previews of some web pages can exhaust the available stack space for the Synapse process due to unbounded recursion. This is sometimes recoverable and leads to an error for the request causing the problem, but in other cases the Synapse process may crash altogether.

It is possible to exploit this maliciously, either by malicious users on the homeserver, or by remote users sending URLs that a local user's client may automatically request a URL preview for. Remote users are not able to exploit this directly, because the URL preview endpoint is authenticated.

Am I affected?

deployments with urlpreviewenabled: false set in configuration are not affected. deployments with urlpreviewenabled: true set in configuration are affected. deployments with no configuration value set for urlpreviewenabled are not affected, because the default is false.

Patches

Administrators of homeservers with URL previews enabled are advised to upgrade to v1.61.1 or higher.

Workarounds

URL previews can be disabled in the configuration file by setting urlpreviewenabled: false. Deployments using workers can choose to offload URL previews to one or more dedicated worker(s), ensuring that a process crash does not disrupt other functionality of Synapse.

For more information

If you have any questions or comments about this advisory, e-mail us at security@matrix.org.

Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript. Prior to version 19.7.0, 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 strategy on the receiving end. Starting with version 19.7.0, 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. 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 homeserver and an attacker, and those who trust your homeservers do not need a workaround.

Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript. Starting with version 17.1.0-rc.1, improperly formed beacon events can disrupt or impede the matrix-js-sdk from functioning properly, potentially impacting the consumer's ability to process data safely. Note that the matrix-js-sdk can appear to be operating normally but be excluding or corrupting runtime data presented to the consumer. This is patched in matrix-js-sdk v19.7.0. Redacting applicable events, waiting for the sync processor to store data, and restarting the client are possible workarounds. Alternatively, redacting the applicable events and clearing all storage will fix the further perceived issues. Downgrading to an unaffected version, noting that such a version may be subject to other vulnerabilities, will additionally resolve the issue.

Dendrite is a Matrix homeserver written in Go. In affected versions events retrieved from a remote homeserver using the /getmissingevents path did not have their signatures verified correctly. This could potentially allow a remote homeserver to provide invalid/modified events to Dendrite via this endpoint. Note that this does not apply to events retrieved through other endpoints (e.g. /event, /state) as they have been correctly verified. Homeservers that have federation disabled are not vulnerable. The problem has been fixed in Dendrite 0.9.8. Users are advised to upgrade. There are no known workarounds for this issue.

matrix-react-sdk is a Matrix chat protocol SDK for React Javascript. Events sent with special strings in key places can temporarily disrupt or impede the matrix-react-sdk from functioning properly, such as by causing room or event tile crashes. The remainder of the application can appear functional, though certain rooms/events will not be rendered. This issue has been fixed in matrix-react-sdk 3.53.0 and users are advised to upgrade. There are no known workarounds for this vulnerability.

Impact

When users update their passwords, the new credentials may be briefly held in the server database. While this doesn't grant the server any added capabilities—it already learns the users' passwords as part of the authentication process—it does disrupt the expectation that passwords won't be stored in the database. As a result, these passwords could inadvertently be captured in database backups for a longer duration.

These temporarily stored passwords are automatically erased after a 48-hour window.

Patches https://github.com/matrix-org/synapse/pull/16272

References

This bug was due to a regression in https://github.com/matrix-org/synapse/pull/13188.

Impact A malicious server ACL event can impact performance temporarily or permanently leading to a persistent denial of service.

Homeservers running on a closed federation (which presumably do not need to use server ACLs) are not affected.

Patches Server administrators are advised to upgrade to Synapse 1.94.0 or later.

Workarounds Rooms with malicious server ACL events can be purged and blocked using the admin API.

Impact Unauthorised users can access the name, avatar, topic and number of members of a room if they know the ID of the room. This vulnerability is limited to homeservers where: - the vulnerable homeserver is in the room; and - untrusted users are permitted to create groups (communities).

By default, only homeserver administrators can create groups. However, homeserver administrators can already access this information in the database or using the admin API. As a result, only homeservers where the configuration setting enablegroupcreation has been set to true are impacted.

Patches Server administrators should upgrade to 1.41.1 or higher.

Workarounds Server administrators can set enablegroupcreation to false in their homeserver configuration (this is the default value) to prevent creation of groups by non-administrators.

Administrators that are using a reverse proxy could, with partial loss of group functionality, block the following endpoints: /matrix/client/r0/groups/{groupid}/rooms /matrix/client/unstable/groups/{groupid}/rooms

References n/a

For more information If you have any questions or comments about this advisory, e-mail us at security@matrix.org.

The Matrix specification before 1.16 (i.e., with a room version before 12 and State Resolution before 2.1) has deficient state resolution.

Impact

In Synapse versions before 1.120.1, enabling the dynamicthumbnails option or processing a specially crafted request could trigger the decoding and thumbnail generation of uncommon image formats, potentially invoking external tools like Ghostscript for processing.

This significantly expands the attack surface in a historically vulnerable area, presenting a risk that far outweighs the benefit, particularly since these formats are rarely used on the open web or within the Matrix ecosystem.

For a list of image formats, as well as decoding libraries and helper programs used, see the Pillow documentation.

Patches

Synapse 1.120.1 addresses the issue by restricting thumbnail generation to images in the following widely used formats: PNG, JPEG, GIF, and WebP.

Workarounds

- Ensure any image codecs and helper programs, such as Ghostscript, are patched against security vulnerabilities. - Uninstall unused image decoder libraries and helper programs, such as Ghostscript, from the system environment that Synapse is running in. - Depending on the installation method, there may be some decoder libraries bundled with Pillow and these cannot be easily uninstalled. - The official Docker container image does not include Ghostscript.

References

- The Pillow documentation includes a list of supported image formats and which libraries or helper programs are used to decode them.

For more information

If you have any questions or comments about this advisory, please email us at security at element.io.

Impact

Synapse versions before 1.120.1 fail to properly validate invites received over federation. This vulnerability allows a malicious server to send a specially crafted invite that disrupts the invited user's /sync functionality.

Patches

Synapse 1.120.1 rejects such invalid invites received over federation and restores the ability to sync for affected users.

Workarounds

Server administrators can disable federation from untrusted servers.

For more information

If you have any questions or comments about this advisory, please email us at security at element.io.

Impact

In certain configurations, data sent by remote servers containing special strings in key locations could cause modifications of the Object.prototype, disrupting matrix-js-sdk functionality, causing denial of service and potentially affecting program logic.

(This is part 2, where CVE-2022-36059 / GHSA-rfv9-x7hh-xc32 is part 1. Part 2 covers remaining vectors not covered by part 1, found in a codebase audit scheduled after part 1.)

Patches The issue has been patched in matrix-js-sdk 24.0.0.

Workarounds None.

References

- Release blog post - The advisory GHSA-rfv9-x7hh-xc32 (CVE-2022-36059) refers to an initial set of vulnerable locations discovered and patched in matrix-js-sdk 19.4.0. We opted not to disclose that advisory while we performed an audit of the codebase and are now disclosing it jointly with this one.

For more information If you have any questions or comments about this advisory please email us at security at matrix.org.

Impact A discovered oEmbed or image URL can bypass the urlpreviewurlblacklist setting potentially allowing server side request forgery or bypassing network policies. Impact is limited to IP addresses allowed by the urlpreviewiprangeblacklist setting (by default this only allows public IPs) and by the limited information returned to the client:

For discovered oEmbed URLs, any non-JSON response or a JSON response which includes non-oEmbed information is discarded. For discovered image URLs, any non-image response is discarded.

Systems which have URL preview disabled (via the urlpreviewenabled setting) or have not configured a urlpreviewurlblacklist are not affected.

Because of the uncommon configuration required, the limited information a malicious user, and the amount of guesses/time the attack would need; the severity is rated as low.

Patches

The issue is fixed by #15601.

Workarounds

The default configuration of the urlpreviewiprangeblacklist should protect against requests being made to internal infrastructure, URL previews of public URLs is expected.

Alternately URL previews could be disabled using the urlpreviewenabled setting.

Impact

Synapse instances with the media repository enabled can be tricked into downloading a file from a remote server into an arbitrary directory, potentially outside the media store directory.

The last two directories and file name of the path are chosen randomly by Synapse and cannot be controlled by an attacker, which limits the impact.

Homeservers with the media repository disabled are unaffected. Homeservers configured with a federation whitelist are also unaffected.

Patches Server administrators should upgrade to 1.47.1 or later.

Workarounds Server administrators using a reverse proxy could, at the expense of losing media functionality, block the following endpoints:

/matrix/media/r0/download/{serverName}/{mediaId} /matrix/media/r0/download/{serverName}/{mediaId}/{fileName} /matrix/media/r0/thumbnail/{serverName}/{mediaId}

Alternatively, non-containerized deployments can be adapted to use the hardened systemd config, located at contrib/systemd/override-hardened.conf.

References n/a

For more information

If you have any questions or comments about this advisory, e-mail us at security@matrix.org.

Impact

Synapse versions before 1.106 are vulnerable to a disk fill attack, where an unauthenticated adversary can induce Synapse to download and cache large amounts of remote media. The default rate limit strategy is insufficient to mitigate this. This can lead to a denial of service, ranging from further media uploads/downloads failing to completely unavailability of the Synapse process, depending on how Synapse was deployed.

Patches

Synapse 1.106 introduces a new "leaky bucket" rate limit on remote media downloads to reduce the amount of data a user can request at a time. This does not fully address the issue, but does limit an unauthenticated user's ability to request large amounts of data to be cached.

Workarounds

Synapse deployments can currently decrease the maximum file size allowed, as well as increase request rate limits. However, this does not as effectively address the issue as a dedicated rate limit on remote media downloads.

Server operators may also wish to consider putting media on a dedicated disk or volume, reducing the impact of a disk fill condition.

References

https://en.wikipedia.org/wiki/Leakybucket#Asameter

For more information

If you have any questions or comments about this advisory, please email us at security at element.io.

Impact Users were able to forge read receipts for any event (if they knew the room ID and event ID). Note that the users were not able to view the events, but simply mark it as read. This could be confusing as clients will show the event as read by the user, even if they are not in the room.

Patches https://github.com/matrix-org/synapse/pull/16327

Workarounds There is no workaround.

Impact Cached device information of remote users can be queried from Synapse. This can be used to enumerate the remote users known to a homeserver.

Patches System administrators are encouraged to upgrade to Synapse 1.95.1 as soon as possible.

Workarounds The federationdomainwhitelist can be used to limit federation traffic with a homeserver.

Impact

A malicious user on a Synapse homeserver X with permission to create certain state events can disable outbound federation from X to an arbitrary homeserver Y.

Synapse instances with federation disabled are not affected.

Details

The Matrix protocol allows homeservers to provide an inviteroomstate field on a room invite containing a summary of room state. In versions of Synapse up to and including v1.73.0, Synapse did not limit the size of inviteroomstate, meaning that it was possible to create an arbitrarily large invite event.

An attacker with an account on a vulnerable Synapse homeserver X could exploit this by having X create an over-sized invite event in a room with a user from another homeserver Y. Once acknowledged by the invitee's homeserver, the invite event would be sent in a batch of events to Y. If the malicious invite is so large that the entire batch is rejected as too large, X's outgoing traffic to Y would become "stuck", meaning that messages and state events created by X would remain unseen by Y.

Patches

Synapse 1.74 refuses to create oversized inviteroomstate fields. Server operators should upgrade to Synapse 1.74 or newer urgently.

Workarounds

There are no robust workarounds.

This attack needs an account on Synapse homeserver X to deny federation from X to another homeserver Y. As a partial mitigation, Synapse operators can disable open registration to limit the ability of attackers to create new accounts on homeserver X.

If homeserver X has been attacked in this way, restarting it will resume outgoing federation by entering "catchup mode". For catchup mode to ignore the oversized invites, every attacked room must have a correctly-sized event sent by X which is newer than any oversized invite. This is difficult to arrange, and does not prevent the attacker from repeating their attack.

References

- https://github.com/matrix-org/synapse/issues/14492 was caused by this issue. - https://github.com/matrix-org/synapse/issues/14642 includes the patch described above.

For more information

If you have any questions or comments about this advisory, e-mail us at security@matrix.org.

Impact It may be possible for a deactivated user to login when using uncommon configurations.

This only applies if any of the following are true:

JSON Web Tokens are enabled for login via the jwtconfig.enabled configuration setting The local password database is enabled via the passwordconfig.enabled and passwordconfig.localdbenabled configuration settings and a user's password is updated via an admin API after a user is deactivated.

Note that the local password database is enabled by default, but it is uncommon to set a user's password after they've been deactivated.

Installations that are configured to only allow login via Single Sign-On (SSO) via CAS, SAML or OpenID Connect (OIDC); or via an external password provider (e.g. LDAP) are not affected.

Patches

If using JSON Web Token logins: #15624 For other users: #15634

Workarounds

If not using JSON Web Tokens, ensure that deactivated users do not have a password set. This list of users can be queried from PostgreSQL:

sql SELECT name FROM users WHERE passwordhash IS NOT NULL AND deactivated = 1;

Impact

A logic error in the room key sharing functionality of matrix-js-sdk before 12.4.1 allows a malicious Matrix homeserver† participating in an encrypted room to steal room encryption keys from affected Matrix clients participating in that room. This allows the homeserver to decrypt end-to-end encrypted messages sent by affected clients.

† Or anyone with access to the account of the original recipient of an encrypted message.

Known clients affected (via their use of vulnerable versions of matrix-js-sdk):

- Element Web (1.8.2 and earlier) - Element Desktop (1.8.2 and earlier) - SchildiChat Web (1.7.32-sc1 and earlier) - SchildiChat Desktop (1.7.32-sc1 and earlier) - Cinny (1.2.0 and earlier)

Patch

This was fixed in https://github.com/matrix-org/matrix-js-sdk/commit/894c24880da0e1cc81818f51c0db80e3c9fb2be9.

Workarounds To prevent a homeserver from being able to steal the room keys, vulnerable clients can be taken offline or signed out. If signing out, care should be taken to either set up Secure Backup or export E2E room keys in order to preserve access to past messages.

Impact

A malicious or poorly-implemented homeserver can inject malformed events into a room by specifying a different room id in the path of a /sendjoin, /sendleave, /invite or /exchangethirdpartyinvite request.

This can lead to a denial of service in which future events will not be correctly sent to other servers over federation.

This affects any server which accepts federation requests from untrusted servers.

Patches

Issue is resolved by https://github.com/matrix-org/synapse/pull/8776.

Workarounds

Homeserver administrators could limit access to the federation API to trusted servers (for example via federationdomainwhitelist).