XMPP: presence-_pending map onbegrensd — geheugen-DoS via nep-afzenders #1413

New issue

Closed

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

brenno commented

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

Owner

Bevinding

lib/xmpp/xmpp_presence_beacon.dart — de _pending-map (regel 85) is een Map<String, SealedEnvelope> zonder cap, gekoppeld op senderDevice. handlePresence (regels 128–145) voegt elke inbound <pos>-stanza toe aan _pending onder het senderDevice uit de verzegeling. Als de afzender onbekend is in de directory (directory.resolve retourneert null), blijft de entry in _pending staan — _tryOpen retourneert vroegtijdig (regel 160) zonder de entry te verwijderen.

Wat er gebeurt

Een vijandige server (of een occupant die groupchat-messages stuurt met een verzonnen senderDevice in de verzegeling) kan de _pending-map onbegrensd laten groeien. Elke unieke senderDevice voegt een entry toe die nooit wordt verwijderd (omdat directory.resolve null retourneert voor een onbekend device). De map groeit tot het geheugen op is.

In tegenstelling tot het transport (_maxDeferred = 256) en de MUC (_maxOccupants = 500) heeft de presence-beacon geen cap op _pending.

Trust boundary

MUC (companion room) → Applicatie (presence-buffer). Een occupant kan stanzas sturen met een willekeurig senderDevice in de verzegeling.

Impact

Geheugen-exhaustie door een stroom stanzas met unieke nep-senderDevice-waarden. De aanval is stil — geen foutmelding, gewoon groeiend geheugengebruik.

Oplossingsrichting

Begrens _pending met een cap (bijv. 256 of gelijk aan pinStoreCap). Bij overflow verdrijf een willekeurige of oudste entry.
Aanvullend: overweeg een time-out of ronden-teller op _pending-entries — een presence die na N retryPending-ronden nog niet openbaar is, wordt fail-closed gedropt.

Locatie

lib/xmpp/xmpp_presence_beacon.dart regels 84–85 (_pending-declaratie), 128–145 (handlePresence), 150–154 (retryPending), 156–182 (_tryOpen)

Severity

MEDIUM — geheugen-DoS, reëel bij een vijandige server of occupant.

## Bevinding `lib/xmpp/xmpp_presence_beacon.dart` — de `_pending`-map (regel 85) is een `Map<String, SealedEnvelope>` zonder cap, gekoppeld op `senderDevice`. `handlePresence` (regels 128–145) voegt elke inbound `<pos>`-stanza toe aan `_pending` onder het `senderDevice` uit de verzegeling. Als de afzender onbekend is in de directory (`directory.resolve` retourneert `null`), blijft de entry in `_pending` staan — `_tryOpen` retourneert vroegtijdig (regel 160) zonder de entry te verwijderen. ### Wat er gebeurt Een vijandige server (of een occupant die groupchat-messages stuurt met een verzonnen `senderDevice` in de verzegeling) kan de `_pending`-map onbegrensd laten groeien. Elke unieke `senderDevice` voegt een entry toe die nooit wordt verwijderd (omdat `directory.resolve` null retourneert voor een onbekend device). De map groeit tot het geheugen op is. In tegenstelling tot het transport (`_maxDeferred = 256`) en de MUC (`_maxOccupants = 500`) heeft de presence-beacon geen cap op `_pending`. ### Trust boundary MUC (companion room) → Applicatie (presence-buffer). Een occupant kan stanzas sturen met een willekeurig `senderDevice` in de verzegeling. ### Impact Geheugen-exhaustie door een stroom stanzas met unieke nep-`senderDevice`-waarden. De aanval is stil — geen foutmelding, gewoon groeiend geheugengebruik. ### Oplossingsrichting 1. **Begrens `_pending`** met een cap (bijv. 256 of gelijk aan `pinStoreCap`). Bij overflow verdrijf een willekeurige of oudste entry. 2. **Aanvullend:** overweeg een time-out of ronden-teller op `_pending`-entries — een presence die na N `retryPending`-ronden nog niet openbaar is, wordt fail-closed gedropt. ### Locatie - `lib/xmpp/xmpp_presence_beacon.dart` regels 84–85 (`_pending`-declaratie), 128–145 (`handlePresence`), 150–154 (`retryPending`), 156–182 (`_tryOpen`) ### Severity MEDIUM — geheugen-DoS, reëel bij een vijandige server of occupant.

brenno added the

bug

security

labels

2026-08-09 18:23:13 +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