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 1 month 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 5 weeks ago
TehPers@beehaw.org 1 month 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 1 month 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 1 month ago
I’m inclined to agree. This looks like a misunderstanding of RFC 5735.
dan@upvote.au 1 month ago
which was based on RFC 1122, which states:
(section 3.3.6 just talks about broadcasts)
drwho@beehaw.org 5 weeks 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 5 weeks ago
I wasn’t disagreeing with you :) or at least I think I wasn’t. I was just quoting the RFC you linked to.