RequestTracker allows arbitrary gaps across request flows #68

New Issue

Skipper · 2026-04-05T16:23:09Z

Skipper commented

2026-04-05 16:23:09 +00:00

Info

Severity: LOW
Attack vector: network-only

Impact

May let an attacker preallocate request identifiers for later protocol flows, with limited practical effect.

Description

RequestTracker enforces monotonic IDs but permits arbitrary gaps and does not track IDs separately per request kind. That weakens sequencing guarantees across unrelated flows.

Example flow

Send requests that advance the global request counter.
Leave large gaps in the accepted ID space.
Reuse expectations about future request IDs in another flow.
Benefit from weaker request sequencing guarantees.

Mitigation

Track request identifiers per flow or request type and tighten validation of expected sequences.

# Info **Severity**: **LOW** Attack vector: network-only ## Impact May let an attacker preallocate request identifiers for later protocol flows, with limited practical effect. ## Description `RequestTracker` enforces monotonic IDs but permits arbitrary gaps and does not track IDs separately per request kind. That weakens sequencing guarantees across unrelated flows. ## Example flow 1. Send requests that advance the global request counter. 2. Leave large gaps in the accepted ID space. 3. Reuse expectations about future request IDs in another flow. 4. Benefit from weaker request sequencing guarantees. ## Mitigation Track request identifiers per flow or request type and tighten validation of expected sequences.

CleverWild commented

2026-06-19 12:03:23 +00:00

The gap issue is already partially bounded by the checked_add overflow guard. Splitting the tracker per flow would require every request type to carry a flow-type tag in the protobuf message, which is a protocol change. Banning gaps entirely (require id== next_request_id) would be a smaller, self-contained code change with no protocol impact worth considering as a minimal tightening if you want to close this.

The gap issue is already partially bounded by the `checked_add` overflow guard. Splitting the tracker per flow would require every request type to carry a flow-type tag in the protobuf message, which is a protocol change. Banning gaps entirely (require `id`== `next_request_id`) would be a smaller, self-contained code change with no protocol impact worth considering as a minimal tightening if you want to close this.

Skipper closed this issue

2026-06-19 17:15:51 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MarketTakers/arbiter#68