This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Handle state pulled in via backfill more robustly #10794
Labels
A-Messages-Endpoint
/messages client API endpoint (`RoomMessageListRestServlet`) (which also triggers /backfill)
O-Uncommon
Most users are unlikely to come across this or unexpected workflow
S-Tolerable
Minor significance, cosmetic issues, low or no impact to users.
T-Enhancement
New features, changes in functionality, improvements in performance, or user-facing enhancements.
Comments
anoadragon453
added
the
T-Enhancement
MadLittleMods
added
the
A-Messages-Endpoint
|
Related to #10764 |
|
Is this detail important enough to be specced? |
DMRobertson
added
S-Tolerable
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Synapse goes to great lengths to ensure that malicious servers cannot replace the current state of the room by sending an event
Ethat points to all existing forward extremities plus a fake event that the server refuses to divulge. Naively, the server would ask for the state atE, which would then become the current state asEis the new forward extremity, instead Synapse rejects the event if the server refuses to divulge any ofE's prev events. This ensures that the new current state cannot be replaced by malicious servers (without it being resolved against some existing state the server already has).Currently, this logic only applies to newly received events, rather than events that come in via backfill. However, the same attack could be done via backfill in the same way. Thankfully, Synapse currently does not replace forwards extremities when events come in via backfill so Synapse isn't vulnerable to the attack, but that is very tenuous protection and we should add more explicit checks and protections.
The text was updated successfully, but these errors were encountered: