Deprecate 0.0.0.0 for Private Network Access | Hacker News Reader

Deprecate 0.0.0.0 for Private Network Access

chromestatus.com

60 pointscampuscodi29 comments

> 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?

[flagged]

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?

i fail to see much difference with:

>>develop their tools / libraries according to whatever they feel it is the cool kids currently do?<<

versus:

>>adhere to the letter of the spec maliciously instead of understanding current practice.<<

Yes, I do. You should be following de-facto real world standards, not fantasy ones. Especially if security is involved.

If there are de facto real world standards, why not write them down?

Ask the guys writing the RFC's, not me. Boggles my mind too.

Have you considered replacing/creating/updating RFCs/BCPs relevant to your field?

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.

https://www.rfc-editor.org/rfc/rfc3330

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.

It's not a valid machine address. It's a shortcut that, for example, if you are in the 10.0.0.0/8 network, you can use 0.0.0.1 to refer to 10.0.0.1.

How come this doesn't work on my Fedora Linux PC? If I try to ping 0.0.0.1 it just tries to ping 0.0.0.1 which doesn't respond as it doesn't exist.

Are you /8?

Nope, /24.

Well, this was a surprise to me too, but apparently Linux does this:

   $ ping 0.0.0.0
   PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
   64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.028 ms
   64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.056 ms
   64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.105 ms
   ...

   $ nc 0.0.0.0 22  
   SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
   ...

ping 0 works too. Kinda fun.

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.

This behavior has existed since at least the 1990s on various platforms. Pretty sure I first saw it in SunOS.

No mention of [::]? Maybe they'll discover that one in a couple years.

HN discussion: https://news.ycombinator.com/item?id=41184219

But nothing new:

https://research.nccgroup.com/2023/04/27/state-of-dns-rebind...

https://github.com/nccgroup/singularity/wiki/Protection-Bypa...

thanks for those refs!

I believe uBlockOrigin browser extension has a filter to restrict local access

> 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.

Shouldn't they instead add 0.0.0.0/8 to the list of private networks, because it's possible that 0.0.0.0/8 might be private?

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.

I can’t tell from reading the Chrome page (https://developer.chrome.com/blog/private-network-access-pre...) or the linked WICG draft: do these new protections apply to the usual CORS-bypassing requests: form submissions and ordinary navigation?

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

Is this correct ???

> 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

Reply on news.ycombinator.com