Unbounded log_tail_lines

[pimlock]

Summary

WatchSandbox accepts a log_tail_lines field from the client. If it is 0, the server uses 200; otherwise it uses the client value as-is. There is no upper bound. A client can send a very large value (e.g. u32::MAX) and cause the server to allocate and return a huge tail, contributing to memory use and DoS.

Source Code

• crates/navigator-server/src/grpc.rs: lines 169-173 set log_tail = req.log_tail_lines (or 200 when 0). Line 242 calls state.tracing_log_bus.tail(&sandbox_id, log_tail as usize). No min(log_tail, MAX_TAIL) or similar cap is applied.

---

Originally by @drew on 2026-02-19T09:01:00.083-08:00

[johntmyers]

I believe there is a limit on how many logs the actual gateway/server stores so even if a huge number came in from the client it would not be feasible. To be validated by security review agent.

[johntmyers]

🔒 security-review-agent

Security Review

Determination: Not actionable

Rationale

The issue claims that an unbounded log_tail_lines value from the client can cause the server to allocate and return a huge tail buffer, leading to DoS. After reviewing the code, this is not exploitable due to an existing natural bound on the tail buffer.

Evidence:

1. Tail buffer is capped at 2,000 entries per sandbox. In crates/navigator-server/src/tracing_bus.rs:105-116, DEFAULT_TAIL = 2000 and the publish() method enforces while deque.len() > tail_cap { deque.pop_front(); }. The VecDeque per sandbox can never exceed 2,000 elements.

2. tail() iterates the bounded deque. In crates/navigator-server/src/tracing_bus.rs:78-87, tail() does d.iter().rev().take(max).cloned().collect(). Even if max is u32::MAX (4,294,967,295), take(max) on an iterator over a 2,000-element VecDeque will yield at most 2,000 items. There is no unbounded allocation.

3. No amplification vector. The cloned Vec<SandboxStreamEvent> returned by tail() is at most 2,000 elements regardless of the client-supplied value, so memory and CPU usage are bounded.

Recommendation: While the current code is safe due to the natural bound, adding an explicit min(log_tail, MAX_TAIL) cap in grpc.rs would be good defensive practice and would make the safety property self-documenting. This could be done as a low-priority hardening task, not a security fix.

References

• crates/navigator-server/src/tracing_bus.rs:78-87 — tail() function, iterates bounded deque
• crates/navigator-server/src/tracing_bus.rs:105-116 — DEFAULT_TAIL = 2000, deque cap enforcement
• crates/navigator-server/src/grpc.rs:188-192 — log_tail assignment from client request
• crates/navigator-server/src/grpc.rs:264 — tail() call site