It's 2024 and we're just getting round to stopping browsers insecurely accessing 0.0.0.0 A years-old security oversight has been addressed in basically all web browsers – Chromium-based browsers, including Microsoft Edge and Google Chrome, WebKit browsers like Apple's Safari, and Mozilla's Firefox. It can be – and reportedly has been – exploited by miscreants to get access to software services they shouldn't have …
Seems that they have dragged their feet here - all this supposed focus on security, and you could open a socket in a webpage code to any local port? That could be instant compromise of some serious hardware.
And 0.0.0.0 has been specified in this manner for decades, why you would ever want a browser doing this, I can't fathom.
Security is just an illusion while we're still playing whack-a-mole with "new ideas" as simple as this bypassing all web-based security.
When binding a server address, 0.0.0.0 (INADDR_ANY) means listen on all interfaces. But what is the justification for it being recognised as the local host when used as an address to connect to? I don't recall ever seeing that documented, and what would be the point of 127.0.0.1 if 0.0.0.0 did the same?
https://en.wikipedia.org/wiki/0.0.0.0
"IANA, who allocate IP addresses globally, have allocated the single IP address 0.0.0.0[1] to RFC 1122 section 3.2.1.3. It is named as "This host on this network".
It prohibits this as a destination address in IPv4 and only allows it as a source address under specific circumstances."
It shouldn't be allowed at all, and the 0.0.0.0 we see in various places (e.g. in early DHCP packets as a source before IPs are allocated) is a convention using an address that literally shouldn't ever appear in a valid packet - it's used as a "non-IP" indicator for "no IP" or "listen on all", or even "there is no gateway for this route", etc.
But browsers shouldn't be allowing it to create a packet with that as the destination, and there's no real use for listening to packets on that address (so it simply shouldn't be possible in the OS anyway).
No packet should ever be created using 0.0.0.0 as a destination, and thus no webpage should ever be able to send requests/packets to 0.0.0.0.
However, even if the OS allows it, the browser certainly shouldn't be treating it as somewhere that webpages can open Websockets etc. to.
No packet should ever be created using 0.0.0.0 as a destination, and thus no webpage should ever be able to send requests/packets to 0.0.0.0.
Those aren't the same things.
When my application sends to 0.0.0.0, my network stack sends packets to the subnet broadcast address. BSD sockets. Always has been.
I understand that there are reasons for restricting web browsers to only common use cases, blocking uncommon use cases. I'm not saying that your generic user-level applications have to accept 0.0.0.0 as an IP destination, as some other application do. I don't know if this feature was included, like the now gone FILE: protocol, because it was useful, or if it just fell out of the code.
I just note that the exploit reported in this article does not require 0.0.0.0 packets at the (RFC-1122) link or IP layer.
It doesn't do the same as loopback, here 0.0.0.0 means all interfaces on this computer (one of which is loopback). A computer may be assigned more than one IP if it has more than one interface.
To be honest I can't see the problem with treating it as its own isolated origin, if there is compatibility to be maintained then it was something pretty strange in the first place.
If the browser treats 0.0.0.0 as its own origin, it would only allow connections to 0.0.0.0 from web pages served from 0.0.0.0, which seems to me to be as good a way as any of fixing it.
But perhaps it's easiest just to not allow any connections to/from 0.0.0.0.
Well, besides DHCP or BootP.
The browser is one thing, but is there another can of worms hidden?
I run plug-ins to block un-approved 3rd party scripts. Adverts can serve malware. That's one mitigation against this malicious activity.
Yet some stupid sites block you entirely if they think you are blocking adverts. Run the adverts on your own systems. you morons.
[0.0.0.0 for its sins was also the broadcast address in pre 4.3 BSD.]
The problem I think is mostly in the browser's abilitity to run code (scripts) "locally" chosen by a remote site's owner.
Access to the network services running on the browser's host is normally permitted to local processes which the browser is.
In the case of a network service bound to 127.0.0.1 (localhost) only local processes can access that service.
Unfortunately 0.0.0.0 means this host and includes all active configured interfaces including lo0.
It isn't just network services running on the host but any services behind the organisation's firewall(s) that the host has access to.
Any fix would have to be in the browser presumably by controlling those addresses that scripts running in the browser have access to, as the networking stack is working as expected.
Netfilter (Linux) might be able to distinguish a local process connect(2)ing to 0.0.0.0:<port> which would actually connect to 127.0.0.1:<port> as against a local process connecting explicitly to 127.0.0.1:<port> and could incorporate rules to prevent the first but allow the second.
As I'm reading this the issue is a web browser, connecting to a remote site, receiving <some script> that contains instructions to have the browser connect to 0.0.0.0:xyz.
This would have local process (browser) connect to localhost:xyz.
If you want to use iptables to cap this, I believe you want to use OUTPUT or possibly PREROUTING tables. I'm inclined to suggest adding the DROP for 0.0.0.0 to *all* of the tables myself,
INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING
Furthermore, since this is covering all connections happening on the network layer I'd add a -j LOG to that so you know what you're killing.
Test it yourself. I routinely use that address, and also 'localhost', in the location bar. CUPS for example is localhost:631. None of the browsers here make any fuss about it.
This is I think why at least the Mozilla foundation is wary of changing the behaviour of their browser.
I also routinely see attackers from outside my LAN trying to con my services into believing that the connecting host's name is 'localhost.localdomain' or that its IP address is '0.0.0.0', '127.0.0.1', '10.pick.3.numbers' or some such nonsense. None of that will succeed here at least.
Using access list on a border router, I ran across crafted packets that had 127.0.0.1 as the return address.
Upon closer inspection, firewalls passed the packer and did not log it. That made it so you could not block it by firewall. Access rules on the router was the only way.
Using the TTL of the tcp packet we were able to see it was only a few hops away. With the isp’s assist we were able to find the server. It was using massive bandwidth, 100m back then, to hit large blocks of address.
Looking at the packet, it appeared to be a one way command structure. It was in a foreign collage students room.
Beware of device logs. Manufactures will suppress logs their traffic, especially local. They don’t want you to be aware of phoning home.
Test it yourself. I routinely use that address, and also 'localhost', in the location bar. CUPS for example is localhost:631. None of the browsers here make any fuss about it.
Nor should they.
The problem happens when a page from the public Internet gets to talk to 0.0.0.0:631. Connections from a public page to localhost:631 and 127.0.0.1:631 are denied but connections talking to that same CUPS server on 0.0.0.0:631 are allowed.
Typically, (on my machine at least) they do not block that request. And it would be obviously detrimental to do so in many cases (CUPS printing for one, numerous applications including apache, MySQLAdmin, weblogic, Oracle DB, etc etc use localhost, 127.0.0.1, as an administration access point BY DEFAULT)
There was a short period when Falkon went twitchy about it, popping a security issue, but that has since disappeared in my experience.
About time we implemented a single-origin-only policy. Any given tab can only talk to the domain in the address bar. Force ads to be hosted on the server, and make third-party cookies impossible.
While we're at it, how about a dramatic reduction in what code a browser can execute? Stuff to change the appearance or contents of the one page, sure - but can only interact with files selected by an OS-generated Open/Save dialog that the browser can't see or mess with (only request it to be displayed).
"So if you have some service running on your macOS or Linux workstation on port 11223, and you assume no one can reach it because it's behind your firewall, and that your big-name browser blocks outside requests to localhost, guess again because that browser will route a 0.0.0.0:11223 request by a malicious page you're visiting to your service.
It's quite a long shot, in terms of practical exploitation – ..."
Umm, let's see. I'm going to start with 80, 443, 8080, 8443, 5432, 3306,.....
Seriously, there are a bunch of standard ports out there to hit, and the chance that someone is running a local server on a standard port is, to put it mildly, "high".
Yeah, I don't understand how this wasn't squashed hard a LONG time ago...
As I understand it, it's a longshot because a) very few people will to be running critical servers/services on the same device they browse with, and b) if I'm understanding the article correctly, even a successful exploitation of the vulnerability won't allow the attacker to see the request's response, making it basically as useful as a proof of concept. In other words there doesn't seem to be any practical use for the exploit.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
