Block access to ::, ::ffff:0:0, and 0.0.0.0

[annevk]

Fixes #1117.

• [x] At least two implementers are interested (and none opposed):
  • N/A
• [x] Tests are written and can be reviewed and commented upon at:
  • Not testable unfortunately
• [x] Implementation bugs are filed:
  • N/A
• [x] MDN issue is filed: N/A
• [x] The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[fogti]

Should this perhaps also include :: (IPv6)?

[MaraJadeLives]

I got concerned when I saw an article on this bug. No offense, but given that y'all haven't patched it yet (thanks for working on this), would this little extension I tried to make for myself help protect me for now, while I wait for your actual, functional fix? https://github.com/MaraJadeLives/0blocker/tree/main

[annevk]

@fogti I thought that could not be represented due to the way URL parsing works, but it seems I'm mistaken. Will have to look at that some more.

I also realized this fix is incorrect as we should block this after resolving an origin to an IP address, not before.

@MaraJadeLives I'm not sure who you mean by "y'all" but I no longer work for Mozilla. Also, this repository hosts the Fetch standard, not any particular implementation.

[annevk]

@fogti @sysrqb @mozfreddyb @ricea could you all please review? Feel free to nominate others as well.

(I looked into the URL Standard and it does seem to properly deal with :: (which is identical to ::0). I had just forgotten about it.)

[valenting]

I believe this should also block IPv4 mapped ::ffff:0.0.0.0

[annevk]

That would be ::ffff:0:0 normalized. Interesting. Will add.

[mozfreddyb]

I think we might need to include 6to4 which also includes v4 addresses in v6. Would that be 2002::/48?

[sysrqb]

While not directly appropriate for this PR, we should think about adding a similar check as part of response blocking, as well. I'm thinking about some proxying protocols where DNS resolution is performed by the proxy, and the results are similarly undefined in that case.

[annevk]

For 6to4 and ::ffff:0:0, wouldn't in those cases the request leave the end user's machine and thus not present the same attack vector? I can understand still wanting to block it in case a client does do something weird or the router is not adequately protected, although technically that should not be our problem.

Then furthermore, are we sure 6to4 and ::ffff:... are the sole mechanisms or are there other ways to end up with IPv4 through IPv6? Is there an RFC perhaps that describes a function that you hand an IPv6 address and it either hands you an IPv4 if it can derive one or null? That'd be somewhat ideal to have here.

cc @ricea @ekinnear @martinthomson

[gibson042]

are we sure 6to4 and ::ffff:... are the sole mechanisms or are there other ways to end up with IPv4 through IPv6?

Definitively not; the Internet Protocol Version 6 Address Space registry includes the deprecated ::/96 "IPv4-compatible IPv6 address" and the IPv6 Special-Purpose Address Registry includes 64:ff9b::/96 as the well-known prefix for algorithmic translations and 64:ff9b:1::/48 as the prefix for local network domain translation. And RFC 6052 also allows networks to use their own self-chosen prefixes.

[annevk]

@davidben do you have any concrete thoughts on what we should do here or know who to ask?

[valenting]

Could we say something like this?

 <li><p>If <var>ipAddresses</var> <a for=set>contains</a> <code>::</code>, <code>::ffff:0:0</code>,
 or <code>0.0.0.0</code>, or <var>ipAddresses</var> contains an IP address that maps to <code>0.0.0.0</code> then return failure.

We should also reference all the known relevant RFCs. I think browsers should be able to determine nat64 prefixes.

[annevk]

Maybe? Though also see my question above about the request already having left the end user's device. Is mapping to 0.0.0.0 still a problem if it happens on some intermediary?