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 access to. It affects the aforementioned browsers on macOS and Linux – and possibly others – but at least not on Windows.
A firm called Oligo Security flagged up the vulnerability this month and named it a 0.0.0.0 Day because it involves the 0.0.0.0 IPv4 address. And it appears at least some attackers have been abusing this flaw since at least the late 2000s – judging by this Mozilla Bugzilla thread from that era, which is still listed as open.
According to Oligo, each of the three browsers' teams have promised to block all access to 0.0.0.0 and also enact their own mitigations to close the localhost loophole.
The problem is as simple as this: If you open a malicious webpage in a vulnerable browser on a vulnerable OS, that page can fire off requests to 0.0.0.0 and a port of its choosing. And if you have servers or other services running locally on your box on that port, those requests will go to it.
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 – but you wouldn't want to find out the hard way that some site hit your local endpoint by luck. In fact, it's wryly amusing this is a thing in 2024.
There are supposed to be security mechanisms in place to prevent external websites from reaching your localhost in this way. Specifically, the Cross-Origin Resource Sharing (CORS) specification, and then the more recent Private Network Access (PNA), which is used by browsers to distinguish between public and non-public networks, and fortify CORS by restricting outside sites' ability to communicate with servers on private networks and host machines.
The Oligo team, however, was able to bypass PNA. The researchers set up a dummy HTTP server running on 127.0.0.1 aka localhost, on port 8080, and was then able to access it from an external public site using JavaScript, by sending a request to 0.0.0.0:8080.
"This means public websites can access any open port on your host, without the ability to see the response," Oligo security researcher Avi Lumelsky reported.
- 'Thousands' of businesses at mercy of miscreants thanks to unpatched Ray AI flaw
- Trio of TorchServe flaws means PyTorch users need an urgent upgrade
- Cloud storage lockers from Microsoft and Google used to store and spread state-sponsored malware
- Small CSS tweaks can help nasty emails slip through Outlook's anti-phishing net
In response to this, Chrome will block access to 0.0.0.0 starting with Chromium 128, and Google will gradually roll out this change to be completed by Chrome 133. Apple has made changes to its WebKit open source software that block access to 0.0.0.0.
Mozilla doesn't have an immediate fix, and has not implemented PNA in Firefox. According to Olgio, Mozilla did change the Fetch specification (RFC) to block 0.0.0.0 following its report.
A Mozilla spokesperson sent The Register the following statement via email:
We are aware that there are services deployed to hosts or local networks that are vulnerable to attack from websites. These services rely on being inaccessible as their only means of defense. The CORS protocol contains safeguards against this risk, but those safeguards contain a number of key exclusions that were deemed necessary to avoid breaking pre-existing usage.
An unspecified address ("0.0.0.0" in IPv4 or "::" in IPv6) is sometimes usable as a means of accessing a service on a device in place of a "loopback" address of "localhost", "127.0.0.1", or "::1". Use of an unspecified address is therefore a specific case of this more general problem.
Mozilla is supportive of efforts to improve the security of these vulnerable services by improving the restrictions in CORS. However, we are aware that imposing tighter restrictions comes with a significant risk of introducing compatibility problems. As the standards discussion and work to understand those compatibility risks is ongoing, Firefox has not implemented any of the proposed restrictions. We plan to continue our engagement in that process.
According to Oligo, this research makes a strong case for PNA.
"Until PNA fully rolls out, public websites can dispatch HTTP requests using Javascript to successfully reach services on the local network," Lumelsky wrote. "For that to change, we need PNA to be standardized, and we need browsers to implement PNA according to that standard." ®
