XMPP: snapshot-_assembled map onbegrensd — gereassembleerde snapshots met onbekende afzender blijven forever staan #1414

New issue

Closed

opened 2026-08-09 18:23:28 +00:00 by brenno · 0 comments

brenno commented

2026-08-09 18:23:28 +00:00

Owner

Bevinding

lib/xmpp/xmpp_snapshot.dart — de _assembled-map (regel 99) is een Map<String, SealedEnvelope> zonder cap. Een snapshot die volledig is gereassembleerd maar niet geopend kan worden (onbekende afzender, of epoch-sleutel nog niet aanwezig) blijft in _assembled staan.

Wat er gebeurt

De _pending-map (chunks) is cap'd op maxPendingSnapshots (4), maar zodra een snapshot is gereassembleerd, verhuist hij van _pending naar _assembled — wat de _pending-slot vrijmaakt voor een nieuwe snapshot. Een vijandige server kan cyclen: 4 snapshots sturen, ze worden gereassembleerd, 4 meer sturen, enzovoort. _assembled groeit onbegrensd.

_tryOpen (regels 224–264) verwijdert een entry alleen bij:

een geslaagde open (regel 242),
een niet-unknown-epoch fout (regel 261),
een eigen echo (regel 229).

Als de afzender onbekend is (directory.resolve retourneert null, regel 232–233), retourneert _tryOpen vroegtijdig zonder de entry te verwijderen. De entry blijft forever staan.

Trust boundary

MUC (companion room) → Applicatie (snapshot-reassemblage). Een occupant kan snapshots sturen met een verzonnen senderDevice.

Impact

Geheugen-exhaustie. Elke gereassembleerde snapshot is een volledige verzegelde baseline (potentieel tientallen KB tot MB). Een vijandige server kan _assembled vullen met honderden nep-snapshots die nooit worden opgeruimd.

Oplossingsrichting

Begrens _assembled met een cap (bijv. 8 of maxPendingSnapshots * 2). Bij overflow verdrijf de oudste entry.
Verwijder entries met onbekende afzender na een time-out — een snapshot waarvan de afzender na N retryPending-ronden nog steeds onbekend is, wordt fail-closed gedropt.
Aanvullend: de afzender-check kan strenger — een snapshot-id bevat de afzender's deviceId; verifieer dat de directory een device met dat deviceId kent vóór reassemblage. Een snapshot van een onbekend device wordt dan geweigerd vóór de chunks worden gebufferd.

Locatie

lib/xmpp/xmpp_snapshot.dart regels 92–99 (_assembled-declaratie), 204–216 (_assemble), 224–264 (_tryOpen)

Severity

MEDIUM — geheugen-DoS, versterkt door het feit dat _pending-cap de aanvaller helpt cyclen.

## Bevinding `lib/xmpp/xmpp_snapshot.dart` — de `_assembled`-map (regel 99) is een `Map<String, SealedEnvelope>` zonder cap. Een snapshot die volledig is gereassembleerd maar niet geopend kan worden (onbekende afzender, of epoch-sleutel nog niet aanwezig) blijft in `_assembled` staan. ### Wat er gebeurt De `_pending`-map (chunks) is cap'd op `maxPendingSnapshots` (4), maar zodra een snapshot is gereassembleerd, verhuist hij van `_pending` naar `_assembled` — wat de `_pending`-slot vrijmaakt voor een nieuwe snapshot. Een vijandige server kan cyclen: 4 snapshots sturen, ze worden gereassembleerd, 4 meer sturen, enzovoort. `_assembled` groeit onbegrensd. `_tryOpen` (regels 224–264) verwijdert een entry alleen bij: - een geslaagde open (regel 242), - een niet-`unknown-epoch` fout (regel 261), - een eigen echo (regel 229). Als de afzender onbekend is (`directory.resolve` retourneert `null`, regel 232–233), retourneert `_tryOpen` vroegtijdig **zonder de entry te verwijderen**. De entry blijft forever staan. ### Trust boundary MUC (companion room) → Applicatie (snapshot-reassemblage). Een occupant kan snapshots sturen met een verzonnen `senderDevice`. ### Impact Geheugen-exhaustie. Elke gereassembleerde snapshot is een volledige verzegelde baseline (potentieel tientallen KB tot MB). Een vijandige server kan `_assembled` vullen met honderden nep-snapshots die nooit worden opgeruimd. ### Oplossingsrichting 1. **Begrens `_assembled`** met een cap (bijv. 8 of `maxPendingSnapshots * 2`). Bij overflow verdrijf de oudste entry. 2. **Verwijder entries met onbekende afzender na een time-out** — een snapshot waarvan de afzender na N `retryPending`-ronden nog steeds onbekend is, wordt fail-closed gedropt. 3. **Aanvullend:** de afzender-check kan strenger — een snapshot-`id` bevat de afzender's `deviceId`; verifieer dat de directory een device met dat `deviceId` kent vóór reassemblage. Een snapshot van een onbekend device wordt dan geweigerd vóór de chunks worden gebufferd. ### Locatie - `lib/xmpp/xmpp_snapshot.dart` regels 92–99 (`_assembled`-declaratie), 204–216 (`_assemble`), 224–264 (`_tryOpen`) ### Severity MEDIUM — geheugen-DoS, versterkt door het feit dat `_pending`-cap de aanvaller helpt cyclen.

brenno added the

bug

security

labels

2026-08-09 18:23:28 +00:00

brenno referenced this issue

2026-08-09 18:40:19 +00:00

XMPP: testgaten voor unhappy flows — bugs uit #1411-#1430 zijn niet gedekt door regressietests #1434

brenno added the

in-progress

label

2026-08-09 20:04:28 +00:00