Seems like a TCP/IP stack issue rather than a browser issue… 0.0.0.0 is not supposed to be a valid address (in fact, no IPv4 address with 0 as the first octet is a valid destination IP). The network stack should be dropping those packets.
0.0.0.0 is only valid in a few use cases. When listening for connections, it means “listen on all IPs”. This is a placeholder that the OS handles - it doesn’t literally use that IP. Also, it’s used as the source address for packets where the system doesn’t have an IP yet (eg for DHCP). That’s it.
We now summarize the important special cases for Class A, B,
and C IP addresses, using the following notation for an IP
address:
{ <Network-number>, <Host-number> }
or
{ <Network-number>, <Subnet-number>, <Host-number> }
and the notation "-1" for a field that contains all1 bits.
This notation is not intended to imply that the 1-bits in an
addressmask need be contiguous.
...
(a) { 0, 0 }
This host on this network. MUST NOT be sent, except as
a source address as part of an initialization procedure
by which the host learns its own IP address.
See also Section3.3.6 for a non-standard use of {0,0}.
Yeah, I just did a quick test in Python to do a tcp connection to “0.0.0.0” and it made a loopback connection, instead of returning an error as I would have expected.
it makes connecting to localhost as easy as http://0:8080/ (for port 8080, but omit for port 80).
The thing is that it’s not supposed to work, so it’s essentially relying on undefined behaviour. Typing [::1]:8080 is nearly as easy.
skimming through these PRs, at least for WebKit, I don’t see tests for shorthand IPs like 0 (and no Apple device to test with). What are the chances they missed those…?
I haven’t seen the PRs, but IP comparison should really be using the binary form of the IPv4 address (a 32-bit number), not the human-friendly form.
Seems like a TCP/IP stack issue rather than a browser issue… 0.0.0.0 is not supposed to be a valid address (in fact, no IPv4 address with
0as the first octet is a valid destination IP). The network stack should be dropping those packets.0.0.0.0is only valid in a few use cases. When listening for connections, it means “listen on all IPs”. This is a placeholder that the OS handles - it doesn’t literally use that IP. Also, it’s used as the source address for packets where the system doesn’t have an IP yet (eg for DHCP). That’s it.I’m inclined to agree. This looks like a misunderstanding of RFC 5735.
which was based on RFC 1122, which states:
We now summarize the important special cases for Class A, B, and C IP addresses, using the following notation for an IP address: { <Network-number>, <Host-number> } or { <Network-number>, <Subnet-number>, <Host-number> } and the notation "-1" for a field that contains all 1 bits. This notation is not intended to imply that the 1-bits in an address mask need be contiguous. ... (a) { 0, 0 } This host on this network. MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its own IP address. See also Section 3.3.6 for a non-standard use of {0,0}.(section 3.3.6 just talks about broadcasts)
Okay, I see where I went wrong. Thank you.
I don’t think 0.0.0.0 works for broadcasts anymore, either - I think those get filtered by default these days.
I wasn’t disagreeing with you :) or at least I think I wasn’t. I was just quoting the RFC you linked to.
Yeah, I just did a quick test in Python to do a tcp connection to “0.0.0.0” and it made a loopback connection, instead of returning an error as I would have expected.
While I agree, it makes connecting to localhost as easy as
http://0:8080/(for port 8080, but omit for port 80).I worry that changing this will cause more CVEs like the octal IP addresses incident.
Edit: looks like it’s only being blocked for outgoing requests from websites, which seems like it’ll have a much more reasonable impact.
The thing is that it’s not supposed to work, so it’s essentially relying on undefined behaviour. Typing
[::1]:8080is nearly as easy.I haven’t seen the PRs, but IP comparison should really be using the binary form of the IPv4 address (a 32-bit number), not the human-friendly form.