Security #8585
closedenip: memory amplification via parse_cip_reqresp_multiple
Description
- Summary
`parse_cip_reqresp_multiple` reads an attacker-controlled `u16` count and passes it directly to `count()`. The count can be as high as 65535, causing large allocation and many recursive CIP parsing iterations.
- Affected Code
File: `rust/src/enip/parser.rs:228-256`
```rust
let (i, nb) = le_u16.parse(i)?; // attacker-controlled, max 65535
let (i, offset_list) = count(le_u16, nb.into()).parse(i)?; // Vec::with_capacity(nb)
```
- Impact
`count()` pre-allocates a Vec with capacity `nb`, causing approximately 128KB heap allocation per packet plus up to 65535 recursive CIP parsing iterations. A small TCP packet with `nb=0xffff` can trigger significant CPU and memory consumption. In ICS environments with low traffic baselines, this can overwhelm a sensor.
- Suggested Fix
Add an upper bound check on `nb`, for example:
```rust
if nb > MAX_CIP_SERVICES { return Err(...); }
```
- Environment
Suricata main branch @ commit 367ca7f (post v8.0.1, May 15, 2026).
- Credit
Reported by Chris Ramos.
PA Updated by Philippe Antoine 17 days ago
I think this should be rejected : 65k is acceptable
We had already looked into this with https://redmine.openinfosecfoundation.org/issues/5279
PA Updated by Philippe Antoine 17 days ago
- Related to Bug #5279: nom: use of count combinator can use too much memory added
JF Updated by Juliana Fajardini Reichow 11 days ago
- Status changed from New to Triaged
JF Updated by Juliana Fajardini Reichow 4 days ago
- Status changed from Triaged to Rejected
- Assignee deleted (
OISF Dev) - Target version deleted (
TBD)
Rejecting this as per Philippe's comment and team's agreement.
JF Updated by Juliana Fajardini Reichow 4 days ago
- Private changed from Yes to No