Skip to content

fix(url_safety): handle DNS64/NAT64 synthesized addresses in SSRF check - #38071

Closed
Elshayib wants to merge 3 commits into
NousResearch:mainfrom
Elshayib:fix/nat64-url-safety
Closed

fix(url_safety): handle DNS64/NAT64 synthesized addresses in SSRF check#38071
Elshayib wants to merge 3 commits into
NousResearch:mainfrom
Elshayib:fix/nat64-url-safety

Conversation

@Elshayib

@Elshayib Elshayib commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Summary

_is_blocked_ip treated IPv6 addresses in the 64:ff9b::/96 well-known prefix as reserved and blocked them unconditionally. This caused false-positive blocks when DNS64 resolvers returned synthesized AAAA records for legitimate public hosts (e.g. www.bhphotovideo.com -> 64:ff9b::6812:27e4 which embeds 104.18.39.228).

Fix

Added NAT64 handling matching the existing ipv4_mapped pattern: extract the embedded IPv4 address from the last 32 bits and run the standard IPv4 SSRF checks on that instead of relying on ip.is_reserved.

  • Dangerous embedded targets (169.254.169.254, 10.x, 127.x, etc.) remain blocked
  • Public embedded targets are correctly allowed

Tests

  • 6 NAT64 parametrize cases added to TestIsBlockedIp (3 blocked, 3 allowed)
  • 6 integration tests in new TestNat64 class covering:
    • public IP allowed via is_safe_url
    • private IP still blocked
    • loopback still blocked
    • cloud metadata still blocked
    • allow_private_urls toggle interaction
    • mixed DNS responses (plain IPv4 + NAT64)

All 128 tests in test_url_safety.py pass.

Fixes #38048

islam666 added 3 commits June 3, 2026 08:37
…t cleanup

- web_server.py: after proc.poll() returns a non-None exit code, call
  proc.wait() to reap the child and move the entry from _ACTION_PROCS
  to _ACTION_RESULTS. Previously .poll() alone left <defunct> zombies.
- meet_bot.py: terminate and wait on the pcm_pump subprocess (paplay/
  ffmpeg) during the finally-block teardown. Previously leaked on every
  normal bot exit.
- tests: add test_action_status_reaps_completed_process and
  test_action_status_ignores_wait_failure covering both the happy path
  and the wait()-raises-OSError edge case.

Closes #38032
The copytree ignore lambda in _copy_dist_payload applied USER_OWNED_EXCLUDE
recursively at every directory depth. This caused nested directories whose
names matched exclude entries (bin, logs, cache, etc.) to be silently dropped
during distribution install/update.

Fix: only apply USER_OWNED_EXCLUDE filtering at the root of the staged tree,
matching the two-tier pattern used by _clone_all_copytree_ignore and
_default_export_ignore in profiles.py.

Add 5 tests covering nested bin/logs/cache preservation and top-level
filtering still working.

Fixes #37954
_is_blocked_ip treated IPv6 addresses in the 64:ff9b::/96 well-known
prefix as reserved and blocked them unconditionally.  This caused
false-positive blocks when DNS64 resolvers returned synthesized AAAA
records for legitimate public hosts (e.g. www.bhphotovideo.com ->
64:ff9b::6812:27e4 which embeds 104.18.39.228).

Add NAT64 handling matching the existing ipv4_mapped pattern: extract
the embedded IPv4 address from the last 32 bits and run the standard
IPv4 SSRF checks on that instead of relying on ip.is_reserved.
Dangerous embedded targets (169.254.169.254, 10.x, 127.x, etc.)
remain blocked; public embedded targets are correctly allowed.

Add 6 NAT64 parametrize cases to TestIsBlockedIp and 6 integration
tests in TestNat64 covering public allowed, private blocked,
loopback blocked, metadata blocked, toggle interaction, and mixed
DNS responses.

All 128 tests in test_url_safety.py pass.

Fixes #38048
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists type/security Security vulnerability or hardening tool/web Web search and extraction duplicate This issue or pull request already exists labels Jun 3, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Duplicate fix: PRs #38058 and #12256 already address #38048 with the same embedded-IPv4 NAT64 decode approach. Maintainers should consolidate on one.

@Elshayib

Elshayib commented Jun 3, 2026

Copy link
Copy Markdown
Contributor Author

Noted — PRs #38058 and #12256 address the same issue. Happy to close this if maintainers prefer one of the other implementations. The approach is the same (decode embedded IPv4 from 64:ff9b::/96 and apply existing IPv4 SSRF checks), so whichever PR is most complete should take priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

duplicate This issue or pull request already exists P2 Medium — degraded but workaround exists tool/web Web search and extraction type/bug Something isn't working type/security Security vulnerability or hardening

Projects

None yet

Development

Successfully merging this pull request may close these issues.

url_safety false-positively blocks DNS64/NAT64 addresses in 64:ff9b::/96

2 participants