Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Prevent the homeserver from inserting malicious secrets
Correctly verify that the reply to a secrets request is actually coming from a verified device. While we did verify that it was us who replied, we didn't properly cancel storing the secret if the sending device was one of ours but was maliciously inserted by the homeserver and unverified. We only send secret requests to verified devices in the first place, so only the homeserver could abuse this issue. Additionally we protected against malicious secret poisoning by verifying that the secret is actually the reply to a request. This means the server only has 2 places where it can poison the secrets: - After a verification when we automatically request the secrets - When the user manually hits the request button It also needs to prevent other secret answers to reach the client first since we ignore all replies after that one. The impact of this might be quite severe. It could allow the server to replace the cross-signing keys silently and while we might not trust that key, we possibly could trust it in the future if we rely on the stored secret. Similarly this could potentially be abused to make the client trust a malicious online key backup. If your deployment is not patched yet and you don't control your homeserver, you can protect against this by simply not doing any verifications of your own devices and not pressing the request button in the settings menu.
- Loading branch information