Failures to correctly validate signatures on transactions and events [CVE-2018-16515]

[richvdh]

This is a placeholder for the security issues identified by CVE-2018-16515.

[richvdh]

There were three separate problems here:

(1) we didn't check that the event was signed by the sender's server. We did check that the event was signed by the "origin" server (see 2, 3), but there is nothing that requires them to be the same. This could have allowed the administrator of any server in a room to forge events from users on other servers in that room, including those users with privileged access levels. In short, it could allow a malicious user to take control of a room.

(2) we checked that the event was signed by whichever server is in the "origin" field in the event, but we didn't check that actually matched the event_id. That meant that a malicious server could spoof an existing event from a benign server, potentially dramatically changing it. We have not fully assessed the impact of this vulnerability, and it should be noted that there remains work to be done to ensure that malicious servers are prevented from manipulating room history by falsifying event content, which is being tracked under matrix-org/matrix-spec-proposals#1640.

(3) for push transactions, we applied server ACLs based on the "origin" field of the transaction, which the sending server was free to set to whatever it likes, rather than whatever the sending server authenticated as: this therefore provided a mechanism for malicious server to evade ACLs. (We also did some other things based on that field, with less serious potential consequences).

[richvdh]

(for clarity: this was fixed in v0.33.3.1 and v0.33.2.1).