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.
Comment on 0.0.0.0 Day - 18 Yr Old Vulnerability Let Attackers Bypass All Browser Security
dan@upvote.au 3 months ago
Seems like a TCP/IP stack issue rather than a browser issue… 0.0.0.0 is not supposed to be a valid address. The network stack should be dropping those packets.
AndrasKrigare@beehaw.org 3 months ago
TehPers@beehaw.org 3 months ago
While I agree, it makes connecting to localhost as easy as
http://0:8080/
(for port 8080, but omit for port 80)dan@upvote.au 3 months ago
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 N 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.
drwho@beehaw.org 3 months ago
I’m inclined to agree. This looks like a misunderstanding of RFC 5735.
dan@upvote.au 3 months ago
which was based on RFC 1122, which states:
(section 3.3.6 just talks about broadcasts)
drwho@beehaw.org 3 months ago
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.
dan@upvote.au 3 months ago
I wasn’t disagreeing with you :) or at least I think I wasn’t. I was just quoting the RFC you linked to.