Python: block Azure WireServer and IPv6-embedded IPv4 in the shared public-address check - #14242

This review comment is correct and I should have answered it sooner. The false positive is real, and it fires on the ordinary case rather than a contrived one. But the suggested remedy would open a hole in the exact thing this PR exists to close, so I want to lay out the measurements before changing anything.

The bug, confirmed. RFC 6052 section 2.2 puts the embedded IPv4 in different byte positions per prefix length, and only /96 puts it in bytes 12 to 15. The suffix, which the RFC says SHOULD be zero, is what lands there for the shorter forms. So a public address embedded with anything but /96 decodes as 0.0.0.0:

8.8.8.8 via /96   64:ff9b:1::808:808        -> decodes 8.8.8.8   not blocked
8.8.8.8 via /48   64:ff9b:1:808:8:800::     -> decodes 0.0.0.0   BLOCKED "unspecified (embedded in IPv6)"
1.1.1.1 via /48   64:ff9b:1:101:1:100::     -> BLOCKED
93.184.216.34     64:ff9b:1:5db8:d8:2200::  -> BLOCKED

But restricting the decode to the /96 shape trades it for a false negative. Same matrix against the address the blocklist is built around:

169.254.169.254        current   with the /96 restriction
  /96 embedding        blocked   blocked
  /64 embedding        blocked   NOT BLOCKED
  /56 embedding        blocked   NOT BLOCKED
  /48 embedding        blocked   NOT BLOCKED

Today those are blocked, though only by accident: the decode reads a zero suffix and rejects 0.0.0.0. Declining to decode makes them pass. So the suggestion fixes over-blocking of public hosts and simultaneously lets 64:ff9b:1:a9fe:a9:fe00:: through to the metadata endpoint, which is the SSRF this PR is about.

Decoding every RFC 6052 length instead does not work either. I tried it. Each wrong interpretation still yields some IPv4, and those spurious readings classify as blocked often enough to be useless:

8.8.8.8 via /96, decoded at all four lengths -> one of the readings is in a blocked range -> blocked

Skipping all-zero readings recovers the /48 case and still gets /96 and /64 wrong. The underlying reason is in RFC 6052 section 3.3: the prefix length is configuration held by the translator, not something carried in the address. Nothing in the packet says which length was used, so any inference is a guess, and both directions of guess are wrong for some input.

What I think the fix is. Split the two prefixes, because they are not the same kind of thing.

64:ff9b::/96 is the well-known prefix and RFC 6052 section 2.1 fixes its length at /96. Decoding bytes 12 to 15 there is unambiguous and correct, so that path stays exactly as it is.

64:ff9b:1::/48 is RFC 8215 local-use space, where the operator picks the length. A generic validator cannot know it. Rather than guess, treat the whole prefix as non-public and block it as its own category. Measured:

well-known 64:ff9b::/96
  169.254.169.254   64:ff9b::a9fe:a9fe    blocked      correct
  8.8.8.8           64:ff9b::808:808      not blocked  correct
  10.0.0.5          64:ff9b::a00:5        blocked      correct

local-use 64:ff9b:1::/48, all four embedding lengths, both targets
  every case                              blocked      uniform, no guessing

No public address gets mislabelled unspecified, and nothing reaches the metadata endpoint through a length this code cannot determine.

The cost is explicit and worth stating in the code: legitimate NAT64 traffic through a local-use prefix is refused. For a server-URL allowlist in an OpenAPI plugin I think that is the right side to err on, and it is a stated policy rather than an accident that reports the wrong reason. If anyone disagrees, the alternative is making the local-use prefix length configurable, which seems like a lot of surface for this.

I will push that unless someone prefers a different call. Thanks to whoever wired up the review here, the byte-offset observation was exactly right.

Pushed as 9bb4d2598.

64:ff9b::/96 keeps its decode, 64:ff9b:1::/48 is now blocked as its own category, and the constant finally matches the comment that was already sitting above it saying only the /96 embedding should be decoded.

Red/green on the new test, reverting only server_url_validator.py:

FAILED test_nat64_local_use_prefix_is_blocked_at_every_embedding_length[1.1.1.1-96]
FAILED test_nat64_local_use_prefix_is_blocked_at_every_embedding_length[1.1.1.1-64]

and with the change in place the whole file passes, 84 tests. ruff check and ruff format --check are clean on both files.

One test moved rather than being added: 64:ff9b:1::1.1.1.1 was in the allowed list, and it is blocked now. That is the deliberate half of the trade, so the new test names all four embedding lengths and both targets to make the policy explicit rather than incidental.

Flagging an overlap so a reviewer does not read the same fix twice.

#14267 covers the same two bypasses this PR does, Azure WireServer being publicly routable and IPv4 smuggled inside NAT64/6to4/Teredo addresses. It was opened on 4 August; this PR and the issue behind it, #14240, are from 29 July.

I am not asking anyone to prefer this one. If #14267 is the better patch, say so and I will close this immediately. What would be unhelpful is both sitting in the queue looking like separate work when only one of them needs reviewing.

The same thing happened one PR over: #14268 overlaps #14241, which came from #14239 on the same date.