Commit: 2f26d91 · Finding: SEC-V-07
Problem
RotateChannelKey.encrypted_keys: Vec<(EndpointId, Vec<u8>)> at crates/state/src/event.rs:151-155 — no cap on outer Vec length or inner bytes length. Unpacked directly into state.channel_keys at crates/state/src/materialize.rs:487-505.Event.deps: Vec<EventHash> at crates/state/src/event.rs:210-212 — no declared maximum.
A ManageChannels-authorised peer can broadcast a RotateChannelKey with one entry per fabricated EndpointId (~7000 entries fit in 256 KB), each .clone()-inserted into BTreeMap<EndpointId, Vec<u8>> on every peer.
Fix
- Cap
encrypted_keys.len() at the current member count + small epsilon (there is no legitimate reason to have entries for non-members).
- Cap individual encrypted-key
Vec<u8> at 128 bytes.
- Cap
deps.len() to a small constant (e.g. 64).
- Reject events violating any of these in
Event::new and/or on inbound wire deserialization.
Obvious fix — will be auto-PR'd.
Commit:
2f26d91· Finding:SEC-V-07Problem
RotateChannelKey.encrypted_keys: Vec<(EndpointId, Vec<u8>)>atcrates/state/src/event.rs:151-155— no cap on outer Vec length or inner bytes length. Unpacked directly intostate.channel_keysatcrates/state/src/materialize.rs:487-505.Event.deps: Vec<EventHash>atcrates/state/src/event.rs:210-212— no declared maximum.A
ManageChannels-authorised peer can broadcast aRotateChannelKeywith one entry per fabricatedEndpointId(~7000 entries fit in 256 KB), each.clone()-inserted intoBTreeMap<EndpointId, Vec<u8>>on every peer.Fix
encrypted_keys.len()at the current member count + small epsilon (there is no legitimate reason to have entries for non-members).Vec<u8>at 128 bytes.deps.len()to a small constant (e.g. 64).Event::newand/or on inbound wire deserialization.Obvious fix — will be auto-PR'd.