Impact A malicious server can craft events which, when received, prevent Synapse version up to 1.127.0 from federating with other servers. The vulnerability has been exploited in the wild.
Patches Fixed in Synapse v1.127.1.
Workarounds Closed federation environments of trusted servers or non-federating installations are not affected.
For more information
If you have any questions or comments about this advisory, please email us at security at element.io.
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 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 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
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 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 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 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 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.
Synapse before 1.52.0 with URL preview functionality enabled will attempt to generate URL previews for media stream URLs without properly limiting connection time. Connections will only be terminated after maxspidersize (default: 10M) bytes have been downloaded, which can in some cases lead to long-lived connections towards the streaming media server (for instance, Icecast). This can cause excessive traffic and connections toward such servers if their stream URL is, for example, posted to a large room with many Synapse instances with URL preview enabled. Version 1.52.0 implements a timeout mechanism which will terminate URL preview connections after 30 seconds. Since generating URL previews for media streams is not supported and always fails, 1.53.0 additionally implements an allow list for content types for which Synapse will even attempt to generate a URL preview. Upgrade to 1.53.0 to fully resolve the issue. As a workaround, turn off URL preview functionality by setting urlpreviewenabled: false in the Synapse configuration file.
Impact
The Matrix specification specifies a list of event authorization rules which must be checked when determining if an event should be accepted into a room.
In versions of Synapse up to and including v1.61, some of these rules are not correctly applied. An attacker could craft events which would be accepted by Synapse but not a spec-conformant server, potentially causing divergence in the room state between servers.
Patches
Administrators of homeservers with federation enabled are advised to upgrade to v1.62.0 or higher.
Workarounds
Federation can be disabled by setting federationdomainwhitelist to an empty list ([]).
References
https://github.com/matrix-org/synapse/pull/13087 https://github.com/matrix-org/synapse/pull/13088
For more information
If you have any questions or comments about this advisory, e-mail us at security@matrix.org.
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.
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 Unauthorised users can access the membership (list of members, with their display names) of a room if they know the ID of the room. The vulnerability is limited to rooms with shared history visibility. Furthermore, the unauthorised user must be using an account on a vulnerable homeserver that is in the room.
Patches Server administrators should upgrade to 1.41.1 or later.
Workarounds Administrators of servers that use a reverse proxy could, with potentially unacceptable loss of functionality, block the following endpoints: /matrix/client/r0/rooms/{roomid}/members with at query parameter /matrix/client/unstable/rooms/{roomid}/members with at query parameter
References n/a
For more information If you have any questions or comments about this advisory, e-mail us at security@matrix.org.
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.
Impact
"Push rules" can specify conditions under which they will match, including eventmatch, which matches event content against a pattern including wildcards.
Certain patterns can cause very poor performance in the matching engine, leading to a denial-of-service when processing moderate length events.
Patches
The issue is patched by https://github.com/matrix-org/synapse/commit/03318a766cac9f8b053db2214d9c332a977d226c.
Workarounds
A potential workaround might be to prevent users from making custom push rules, by blocking such requests at a reverse-proxy.
For more information
If you have any questions or comments about this advisory, email us at security@matrix.org.
Impact Requests to user provided domains were not restricted to external IP addresses when transitional IPv6 addresses were used. Outbound requests to federation, identity servers, when calculating the key validity for third-party invite events, sending push notifications, and generating URL previews are affected. This could cause Synapse to make requests to internal infrastructure on dual-stack networks.
Patches This issue is fixed by #9240.
Workarounds Outbound requests to the following address ranges can be blocked by a firewall, if unused for internal communication between systems:
::ffff/80 ::0000/80 (note that this IP range is considered deprecated by the IETF) 2002::/16 (note that this IP range is considered deprecated by the IETF)
References RFC3056 RFC4291
Impact Missing input validation of some parameters on the groups (also known as communities) endpoints could cause excessive use of disk space and memory leading to resource exhaustion. Additionally clients may have issues rendering large fields.
Patches This issue is fixed by #9321 and #9393.
Workarounds The groups feature can be disabled (by setting enablegroupcreation to False) to mitigate this issue. Note that it is disabled by default.
Other information Note that the groups feature is not part of the Matrix specification and the chosen maximum lengths are arbitrary. Not all clients might abide by them.
Impact Missing input validation of some parameters on the endpoints used to confirm third-party identifiers could cause excessive use of disk space and memory leading to resource exhaustion.
Patches The issue is fixed by #9321.
Workarounds Depending on the needs and configuration of the homeserver a few options are available:
1. Using email as third-party identifiers be disabled by not configuring the email setting. 2. Using phone numbers as third-party identifiers can be disabled by ensuring that accountthreepiddelegates.msisdn is not configured. 3. Additionally, the affected endpoint patterns can be blocked at a reverse proxy:
^/matrix/client/(r0|unstable)/register/email ^/matrix/client/(r0|unstable)/register/msisdn ^/matrix/client/(r0|unstable)/account/password ^/matrix/client/(r0|unstable)/account/3pid
Impact The notification emails sent for notifications for missed messages or for an expiring account are subject to HTML injection. In the case of the notification for missed messages, this could allow an attacker to insert forged content into the email.
The account expiry feature is not enabled by default and the HTML injection is not controllable by an attacker.
Patches This issue is fixed in #9200.
Workarounds For the missed messages notifications:
The notif.html, notifmail.html, and room.html templates can be overridden with custom templates that manually escapes the variables using JInja2's escape filter. See the email.templatedir setting.
For the account expiry notifications:
1. Account expiry can be disabled via the accountvalidity.enabled setting.
2. The noticeexpiry.html template can be overridden with a custom template that manually escapes the variables using JInja2's escape filter. See the email.templatedir setting.
Impact The password reset endpoint served via Synapse was vulnerable to cross-site scripting (XSS) attacks. The impact depends on the configuration of the domain that Synapse is deployed on, but may allow access to cookies and other browser data, CSRF vulnerabilities, and access to other resources served on the same domain or parent domains.
Patches This is fixed in #9200.
Workarounds Depending on the needs and configuration of the homeserver a few options are available:
1. Password resets can be disabled by delegating email to a third-party service (via the accountthreepiddelegates.email setting) or disabling email (by not configuring the email setting).
2. If the homeserver is not configured to use passwords (via the passwordconfig.enabled setting) then the affected endpoint can be blocked at a reverse proxy:
/synapse/client/passwordreset/email/submittoken
3. The passwordresetconfirmation.html template can be overridden with a custom template that manually escapes the variables using JInja2's escape filter. See the email.templatedir setting.
Impact Requests to user provided domains were not restricted to external IP addresses when calculating the key validity for third-party invite events and sending push notifications. This could cause Synapse to make requests to internal infrastructure. The type of request was not controlled by the user, although limited modification of request bodies was possible.
For the most thorough protection server administrators should remove the deprecated federationiprangeblacklist from their settings after upgrading to Synapse v1.25.0 which will result in Synapse using the improved default IP address restrictions. See the new iprangeblacklist and iprangewhitelist settings if more specific control is necessary.
Patches Issue is resolved by #8821. Further improvements to protect homeservers by default were made in #8870 and #8954.
Workarounds Requests to internal IP addresses could be blocked at the system or network level.
Impact A malicious homeserver could redirect requests to their .well-known file to a large file. This can lead to a denial of service attack where homeservers will consume significantly more resources when requesting the .well-known file of a malicious homeserver.
This affects any server which accepts federation requests from untrusted servers.
Patches Issue is resolved by #8950. A bug not affecting the security aspects of this was fixed in #9108.
Workarounds The federationdomainwhitelist setting can be used to restrict the homeservers communicated with over federation.
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).
Impact A denial of service attack against Matrix clients can be exploited by sending an event including invalid JSON data to Synapse. Synapse would relay the data to clients which could crash or hang. Impact is long-lasting if the event is made part of the room state.
Patches At a minimum #8106 and #8291 must be applied. #7372 and #8124 include additional checks.
Workarounds There are no known workarounds.
Upgrading notes If an invalid event is accepted by an earlier Synapse it can become part of the room state and will not be fixed by upgrading Synapse. Redacting the invalid event should avoid clients receiving the invalid event.
Impact The fallback authentication endpoint served via Synapse was vulnerable to cross-site scripting (XSS) attacks. The impact depends on the configuration of the domain that Synapse is deployed on, but may allow access to cookies and other browser data, CSRF vulnerabilities, and access to other resources served on the same domain or parent domains.
Patches This is fixed by #8444, which is included in Synapse v1.21.0.
Workarounds If the homeserver is not configured to use reCAPTCHA, consent (terms of service), or single sign-on then the affected endpoint can be blocked at a reverse proxy:
/matrix/client/r0/auth/./fallback/web /matrix/client/unstable/auth/./fallback/web
Matrix Synapse before 1.5.0 mishandles signature checking on some federation APIs. Events sent over /sendjoin, /sendleave, and /invite may not be correctly signed, or may not come from the expected servers.
An issue was discovered in Matrix Sydent before 1.0.3 and Synapse before 0.99.3.1. Random number generation is mishandled, which makes it easier for attackers to predict a Sydent authentication token or a Synapse random ID.
Matrix Synapse before 0.34.0.1, when the macaroonsecretkey authentication parameter is not set, uses a predictable value to derive a secret key and other secrets which could allow remote attackers to impersonate users.