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

Lack of validation for device keys in Synapse before 1.138.3 and in Synapse 1.139.0 allow an attacker registered on the victim homeserver to degrade federation functionality, unpredictably breaking outbound federation to other homeservers.

Patches

Patched in Synapse 1.138.3, 1.138.4, 1.139.1, and 1.139.2.

Note that even though 1.138.3 and 1.139.1 fix the vulnerability, they inadvertently introduced an unrelated regression. For this reason, it is recommend to skip these releases and upgrading straight to 1.138.4 and 1.139.2.

Workarounds

The vulnerability can only be exploited by users registered on the victim homeserver.

Synapse Mobility 8.0, 8.0.1, 8.0.2, 8.1, and 8.1.1 contain a privilege escalation vulnerability through external control of Web parameter. If exploited, a user of the product may escalate the privilege and access data that the user do not have permission to view by altering the parameters of the search function.

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.

The iShuttle (aka com.synapse.ishuttleuser) application 1.0 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.