Confused-User said:
Presumably, you don't have the relevant ports open, since 0.0.0.0 would find them too. IOW, they're equivalent.
But that raises a question. How is 0.0.0.0 treated differently than 127.0.0.1? That is, what can an attacker do with 0.0.0.0 that they can't do with the traditional loopback?
See my post above. They are not supposed to be anything like each other.
127.0.0.1 (actually, the entire 127.*.*.* subnet) is supposed to be the "loppback" device. Anything you send to it comes back to yourself. It is the correct way to connect to a network service you know to be running on your own host. Packets are not supposed to be sent out over any network interfaces with loopback addresses as source or destination and routers are supposed to discard packets that do.
0.0.0.0 is a "null" address. It is never valid as a destination. It is only supposed to be used as a source address for protocols (like DHCP) when a host is trying to learn its own IP address from a locally-connected address server. Once the local address is configured, it should not be used at all.
There was a pre-standard usage of 0.0.0.0 where it would be used as a broadcast address - equivalent to 255.255.255.255. This is not valid, but some networking stacks will accept it and treat it as an equivalent for compatibility with some very old system software (like BSD Unix version 4.2 and older). But given how old those systems are, I personally think systems today and routers should block anything with a NULL destination address unless explicitly configured otherwise (e.g. by a network administrator who knows he has such ancient systems on his network).
I suspect (and we really need more information) that the macOS/Darwin kernel, which is derived from BSD Unix, probably still has that backward compatibility code. So it (I assume) is handling 0.0.0.0 the same as it would handle 255.255.255.255. But web browser scripting systems that would ordinarily check for a 255.255.255.255 destination may not have been checking for 0.0.0.0, figuring that the host would reject it.
And other kernels (Linux, Windows, etc.) might have similar behavior, again, in the interest of backward compatibility with really old computers, even though there are probably very few of those computers still running these days.
At least that's my best guess.
olavsu1 said:
According to the knowledge so far, 0.0.0.0 is an error, that does not lead nowhere, but a black hole: all incoming stuff -> /dev/null. but using 127.0.0.1 you are specifically pointing at your own host.
If 0.0.0.0 somehow resolves usefully to attacker, this is a problem
It's not supposed to be a black hole, but an invalid address that hosts may (and according to some of the early standards documents, should) be treated as a broadcast address.
The fact that some firewall rules use it to mean "drop this packet" doesn't change this. Hopefully firewall apps that use it in this fashion also make sure that these packets don't leak into the host's network stack, where they might be processed as if they were sent to a broadcast address.
Confused-User said:
This is what safari says when I try a 0.0.0.0 URL:
Safari can't open the page "https://0.0.0.0/index.html" because Safari can't connect to the server "0.0.0.0".
...
Anywhere an attacker can specify 0.0.0.0 in a malicious web page, they can also specify 127.0.0.1. So I repeat, what is special about 0.0.0.0? How does it enable an attack vector that doesn't already exist with 127.0.0.1 (or more generically, "localhost")?Also, your "additional box on the LAN" is useless. It'll never see traffic sourced on client machines going to 0.0.0.0. Unless you mean you want to use it as a filter before traffic ever gets to the client, which will not play well with https. (Or, I suppose, as a proxy. But that's all well understood tech already, and use of all-0 instead of loopback changes nothing there.)
It makes sense that a URL pointing at 0.0.0.0 would fail, since the only conceivable use of that address would be as a (long since deprecated) alternative for a broadcast address. And you can't open TCP connections to a broadcast address.
But that doesn't mean an app or a script couldn't try to send a UDP or raw-IP packet to that address.
As for what's special, don't think about 0.0.0.0 as loopback - it is not. Think about it as broadcast - equivalent to 255.255.255.255. Scripts running in browsers probably shouldn't be able to send to broadcast addresses, and they absolutely should not be sending to deprecated broadcast addresses that all the standards say should not be used.
But it may well be that some browser code (and maybe only along a small number of code-paths) didn't block it, with the (mistaken) assumption that it would always be dropped by the OS kernel.
Other devices on a LAN will see packets with a source address of 0.0.0.0 - that's what DHCP discovery packets look like when a host is trying to learn its own address. They should not see packets with a destination of 0.0.0.0 unless there is a very old host on the network using it as a broadcast address. Modern computers have no legitimate reason to send to this address, but there are always ways to generate illegal packets if your app has sufficient permissions.
