> Chrome's PNA protection can be bypassed using the IP address 0.0.0.0 to access services listening on the localhost on macOS and Linux.
It seems they're saying if you have a service listening to localhost (private), Chrome is supposed to not resolve 0.0.0.0 (public) to localhost, yet it currently does so.
So seems to me they're solving a security bug. But if I got this right, it's surprising how it got like that in the first place, doesn't make sense in any scenario I can think of to resolve 0.0.0.0 to localhost? Why would a browser try to resolve 0.0.0.0 to anything in the first place?
RFC 3330 says you can use it as a source address for "this" host on "this" network, and that 0.0.0.0/8 can be used for other addresses on "this" network.
Interesting. I'd use 192.168.0.0/16 or 10.0.0.0/8 for that, and haven't found a reason yet not to. Using "0.0.0.0" for anything signals something like "I'm not sure what I want to bind it to, just bind to everything available", at least to me.
Fun fact, ping 0 works because 0 is the IP decimal notation of 0.0.0.0. One of my favorite age-old WAF bypass since it doesn't match octet notation regexes that are often in place.
'0.0.0.0' means 'all local host addresses'. Including whatever might be listening on 127.0.0.0/8.
It's just a private network address, and this "vulnerability" is because idiots adhere to the letter of the spec maliciously instead of understanding current practice.
Wait, so you're suggesting developers shouldn't adhere to specs but instead develop their tools / libraries according to whatever they feel it is the cool kids currently do?
> Digitally “fingerprinting” the users of a website is a known technique that has many purposes. The most common legitimate use is to identify returning users
Incidentally, this is not a legitimate use-case. It's insane to me that companies act like blatant violations of the CFAA are okay. You are not authorized to start scanning a user's private network and making requests to internal services because they loaded a web page.
The engineers, managers, and product people involved in doing that kind of thing should be prosecuted for it.
We (i.e. my colleague Dave Taht) got this to work in Linux several years ago. If you have a Linux kernel since 5.2, you can use 0.0.0.0/8 (except 0.0.0.0 itself) as an ordinary IPv4 network.
pls excuse my aged brain, now with a new blood clot.
IIRC adding 0.0.0.0 0.0.0.0 to your hosts file helps ???
On macOS;
% ping 0.0.0.0
PING 0.0.0.0 (0.0.0.0): 56 data bytes
ping: sendto: Socket is not connected
ping: sendto: Socket is not connected
Request timeout for icmp_seq 0
ping: sendto: Socket is not connected
Request timeout for icmp_seq 1
ping: sendto: Socket is not connected
Request timeout for icmp_seq 2
ping: sendto: Socket is not connected
Request timeout for icmp_seq 3
% ping 0
PING 0 (0.0.0.0): 56 data bytes
ping: sendto: Socket is not connected
ping: sendto: Socket is not connected
Request timeout for icmp_seq 0
ping: sendto: Socket is not connected
Request timeout for icmp_seq 1
ping: sendto: Socket is not connected
Request timeout for icmp_seq 2
ping: sendto: Socket is not connected
Request timeout for icmp_seq 3
ping: sendto: Socket is not connected
> IIRC adding 0.0.0.0 0.0.0.0 to your hosts file helps ?
Yup because typically you're not running a webserver on 0.0.0.0, especially not one that listen on ports 80/443 (say in dev you may be listening to 8080 or something).
I mean: on Linux if you ping 0.0.0.0 (or the shortcut "ping 0"), you'll be getting answers from 127.0.0.1.
But as I don't run a webserver on my machine (except a dev one at times, on a specific port which is not 80/443/8080 etc.), routing domains to 0.0.0.0 still works.
I also used in the past dnsmasq to automatically reply NX_DOMAIN when the browser attempts to resolve 0.0.0.0 but atm I'm not even bothering (maybe I should do it again after reading TFA though).
P.S: it's another aging brain answering, so take this with a grain of salt
It seems they're saying if you have a service listening to localhost (private), Chrome is supposed to not resolve 0.0.0.0 (public) to localhost, yet it currently does so.
So seems to me they're solving a security bug. But if I got this right, it's surprising how it got like that in the first place, doesn't make sense in any scenario I can think of to resolve 0.0.0.0 to localhost? Why would a browser try to resolve 0.0.0.0 to anything in the first place?