Suricata

Original report

I would like to privately report a reproducible Suricata RFB parser/logging issue for your triage.

Summary:

The RFB parser accepts two server-controlled string lengths without an RFB-specific per-field cap:

- `rust/src/rfb/parser.rs:parse_server_init()`: `name_length: u32` is used to copy `ServerInit.name`.
- `rust/src/rfb/parser.rs:parse_failure_reason()`: `reason_length: u32` is used to parse and store `FailureReason.reason_string`.

The parsed values are stored in the current transaction, exposed through `rfb.name`, and emitted in EVE JSON:

- `rust/src/rfb/rfb.rs:RFBState::parse_response`
- `rust/src/rfb/logger.rs:log_rfb`
- `rust/src/rfb/detect.rs:rfb_name_get`

I reproduced this with a real Suricata process, not only by source inspection.

Validated environment:

- Source reviewed: current upstream `main`, commit `17dc0653264ecd99dc361147e4847c49fbee9ad1`
- Runtime tested: Docker image `jasonish/suricata:latest`, reporting `Suricata version 8.0.4 RELEASE`
- The runtime build reports `RUST` support.

Reproduction results from a fresh local rerun:

1. Default config, NUL-filled RFB desktop name:
   - pcap: `rfb_name_1040000_nul.pcap`
   - pcap size: `1,144,656` bytes
   - `eve.json` size: `6,249,818` bytes
   - first JSON line length: `6,240,634` chars
   - the RFB event contains `framebuffer.name`

2. Default config, NUL-filled RFB security failure reason:
   - pcap: `rfb_failure_900000_nul.pcap`
   - pcap size: `990,423` bytes
   - `eve.json` size: `5,409,582` bytes
   - first JSON line length: `5,400,400` chars
   - the RFB event contains `server_security_failure_reason`

3. `stream.reassembly.depth: 0`, NUL-filled 8 MiB RFB desktop name:
   - pcap: `rfb_name_8388608_nul8m.pcap`
   - pcap size: `9,228,124` bytes
   - output `eve.json` size: `9,192` bytes
   - no RFB transaction event is emitted
   - Suricata logs:
     - `Mem buffer asked to create buffer with size greater than API limit - 10485760`
     - `Formatted JSON EVE record too large, will be dropped: {"timestamp":"...","event_type":"rfb",...`

The default-config cases show that valid RFB control bytes such as NUL are JSON-escaped as `\u0000`, causing about 5.46x output expansion in a single EVE RFB record. The depth-zero case shows RFB transaction event loss once the expanded EVE record exceeds Suricata's 10 MiB output buffer limit. Flow/stat records still exist in that case, so I am not claiming a total logging bypass.

Impact assessment:

- This is not memory corruption and I am not claiming code execution.
- The default global stream depth bounds raw input near 1 MiB in my tested config, but a remote RFB peer can still cause multi-MiB single-line EVE RFB records.
- With unlimited stream reassembly depth, the same path can suppress the RFB transaction EVE event due to the output buffer limit.
- My conservative classification is low/moderate parser/logging resource amplification and RFB transaction observability loss.

Suggested fix direction:

- Add RFB-specific caps for server desktop name and security failure reason length, or
- use bounded JsonBuilder helpers in the RFB logger:
  - `set_string_limited(...)`
  - `set_string_from_bytes_limited(...)`
- MQTT's `string-log-limit` looks like a useful precedent.

I am attaching a small reproduction package with:

- detailed source/impact notes
- the synthetic pcap generator
- the three pcaps above
- the depth-zero config used for validation
- Suricata logs from the fresh rerun

Per your security policy, I am not requesting a CVE ID directly. Please let me know whether you consider this a security issue, hardening bug, GHSA/CVE-worthy issue, or out of scope.

Credit if appropriate:

- Bin Luo, University of Electronic Science and Technology of China (UESTC)
- I can provide a GitHub handle if you decide to open a GHSA and need one for credits.