sandbox: forensic-egress allowlist is destination-domain-only, so CONNECT-tunneled HTTPS can carry writes through a 'retrieval-only' domain

[Xore]

Finding

Found while researching #3043 (the dormant-wiki agent-coordination/sandbox-escape writeup). That finding's core lesson -- "constrain request EFFECT, not TYPE" -- has a concrete, unexercised instance in sandbox/forensic-egress-squid.conf.

forensic-egress-allowed-domains.txt is headed "Retrieval-only domains available to proxy-aware forensic samples" and lists .github.com, .githubusercontent.com, .github.io, .pastebin.com, etc. But the squid ACL that enforces this is a plain dstdomain allowlist gating CONNECT to ssl_ports (443):

acl allowed_forensic_domains dstdomain "/etc/honeypot-sandbox/allowed-domains.txt"
...
http_access allow sandbox_guest allowed_forensic_domains

Once a CONNECT to an allowed domain is permitted, squid tunnels the TLS session opaquely -- it cannot see, and does not attempt to distinguish, GET from POST/PUT inside it. So "retrieval-only" in the comment is aspirational, not enforced: a detonated sample with git/gh available (or a hand-rolled HTTPS client) can git push/use the GitHub API to write to a repo, gist, or release under an attacker-controlled account on github.com just as easily as it can git clone/pull one. .github.io is GitHub Pages, a shared multi-tenant domain where anyone can stand up <attacker>.github.io -- reachable the same way. pastebin.com accepts pastes via its own write API too.

This is the same request-TYPE-vs-EFFECT confusion #3043's dormant wiki demonstrated (there: a legacy wiki API where a read-typed request had a write effect; here: a domain-scoped CONNECT tunnel where "read-only" is a naming convention, not a technical restriction) -- not a novel bug, but a real gap between the stated intent and the actual enforcement, worth being explicit about since a detonated sample's exfiltration path through this proxy is exactly the scenario docs/sandbox/README.md's controlled-egress mode exists to constrain.

Why it's low urgency, not ignorable

SANDBOX_NETWORK_MODE=controlled is opt-in (isolated is the default per docs/sandbox/README.md), and everything through this proxy is already logged (access_log) and capped (reply_body_max_size 50 MB, request_body_max_size 1 MB) -- so an exfil attempt here is visible after the fact even though it isn't blocked in real time. This is a detection/design-intent gap, not an active unmonitored hole.

Possible directions (not scoped/decided here)

• TLS-terminate (MITM) the proxy for the allowlisted domains specifically so method/verb can actually be inspected -- meaningful engineering lift, and breaks certificate pinning some retrieval targets might use.
• Narrow the comment/intent instead of the mechanism: document that "retrieval-only" describes the operator's expectation of what samples need these domains for, not a technical guarantee, and rely on the request/reply size caps plus log review to catch a write-shaped session.
• Split truly read-only needs (raw file fetch from raw.githubusercontent.com/objects.githubusercontent.com) onto a domain set that could plausibly be method-restricted, from domains that inherently need bidirectional access (github.com itself, for git clone over smart-HTTP, which is not simply GET) -- clarifies which domains are structurally unrestrictable regardless of proxy design.

No code changed by this issue -- filed as a follow-up while #3043 stayed research-only per this round's scope.

[Xore]

Two corrections after re-reading forensic-egress-squid.conf against the finding — one of them raises the severity above what's written above.

1. The size caps don't apply to the tunnel. The "why it's low urgency" paragraph cites reply_body_max_size 50 MB and request_body_max_size 1 MB as bounding this. They don't. Both directives act on HTTP message bodies squid parses; inside an established CONNECT tunnel there is no HTTP for squid to parse, so tunneled bytes are uncapped in both directions. Exfiltration over 443 through an allowlisted domain is size-unbounded, not capped at 1 MB.

What actually survives as mitigation is narrower: the access_log line for the CONNECT — destination host, port and transferred byte counts. Volume is visible after the fact, content is not. That still keeps this out of "active unmonitored hole" territory, but the framing should rest on logging alone, not on caps that never engage.

2. Plain HTTP is allowed too. safe_ports includes 80 and http_access allow sandbox_guest allowed_forensic_domains is not restricted to connect_method, so a plain POST http://pastebin.com/... is permitted as well. That path is subject to request_body_max_size 1 MB, so it's the lesser concern — but the write surface isn't solely the TLS tunnel.

Everything else in the finding holds up against the config as written, including the point that squid's dstdomain is label-anchored and so the evilgithub.com bypass class does not apply here.

Suggested split: option 2 is a one-line change and shouldn't wait on the rest. Rewriting the header of sandbox/forensic-egress-allowed-domains.txt so "Retrieval-only" reads as operator intent rather than a guarantee (plus the same claim in docs/sandbox/README.md, if it repeats it) closes the stated-intent/actual-enforcement mismatch — which is the whole finding — at zero engineering risk, and forecloses neither the MITM nor the domain-split direction. Options 1 and 3 need real design work and can stay unscoped until controlled mode sees more use.

[Xore]

Reviewed and confirmed against the config rather than the description. Two corrections to this issue's own framing were posted earlier in this thread; PR #3075 now lands the cheap half of the fix.

What #3075 changes: documentation only. The allowlist header and the sandbox README no longer describe this as "retrieval-only" / a "retrieval proxy", and both now state the enforcement boundary explicitly — destination filter, CONNECT tunnel opaque to squid, port 80 allowed too, size caps inapplicable to tunneled bytes, access_log as the surviving mitigation, .github.io as shared multi-tenant hosting.

What stays open — this issue is not closed by that PR. The enforcement gap is unchanged: every allowlisted domain remains a bidirectional channel for a proxy-aware sample, with unbounded volume over 443. Both real directions from the issue body are untouched and unforeclosed:

1. TLS interception (MITM) at the proxy, so squid can see method and path inside the tunnel.
2. Splitting the list into read-only and write-capable destinations, with the write-capable set narrowed or dropped.

Per the issue's own assessment those need design work and should wait until SANDBOX_NETWORK_MODE=controlled sees more use. Leaving this open against that.