It's 2024 and we're just getting round to stopping browsers insecurely accessing 0.0.0.0
- Reference: 1723181648
- News link: https://www.theregister.co.uk/2024/08/09/0000_day_bug/
- Source link:
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 attackers have been abusing this flaw since at least the late 2000s – judging by this Mozilla Bugzilla [1]thread from that era, which is still listed as open.
[2]
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.
[3]
[4]
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.
[5]
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 [6]Cross-Origin Resource Sharing (CORS) specification, and then the more recent [7]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.
[8]
"This means public websites can access any open port on your host, without the ability to see the response," Oligo security researcher Avi Lumelsky [9]reported .
[10]'Thousands' of businesses at mercy of miscreants thanks to unpatched Ray AI flaw
[11]Trio of TorchServe flaws means PyTorch users need an urgent upgrade
[12]Cloud storage lockers from Microsoft and Google used to store and spread state-sponsored malware
[13]Small CSS tweaks can help nasty emails slip through Outlook's anti-phishing net
In response to this, Chrome will [14]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 [15]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 [16]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 [17]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 [18]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." ®
Get our [19]Tech Resources
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=354493
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZrXox7e24v-rEphUv-9FLwAAANM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZrXox7e24v-rEphUv-9FLwAAANM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZrXox7e24v-rEphUv-9FLwAAANM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZrXox7e24v-rEphUv-9FLwAAANM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
[7] https://wicg.github.io/private-network-access/
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZrXox7e24v-rEphUv-9FLwAAANM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser
[10] https://www.theregister.com/2024/03/27/ray_ai_framework_bug/
[11] https://www.theregister.com/2023/10/04/shelltorch_vulnerabilities/
[12] https://www.theregister.com/2024/08/08/microsoft_google_cloud_storage_malware/
[13] https://www.theregister.com/2024/08/07/small_css_tweaks_can_help/
[14] https://chromestatus.com/feature/5106143060033536
[15] https://github.com/WebKit/WebKit/pull/29592/files
[16] https://github.com/whatwg/fetch/pull/1763
[17] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
[18] https://github.com/whatwg/fetch/pull/1763
[19] https://whitepapers.theregister.com/
Why is it a loopback address?
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?
Re: Why is it a loopback address?
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.
Re: Why is it a loopback address?
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.
Re: Why is it a loopback address?
It means all interfaces on this computer when bound as a server address. But this is about it being used as a destination, which should just be disallowed by the operating system.
Re: Why is it a loopback address?
Which is, depending on the OS. (I won't wake the demons by telling which OS is NOT vulnerable to that...)
Why does Linux do anything with 0.0.0.0...
Well, besides [1]DHCP or BootP .
The browser is one thing, but is there another can of worms hidden?
[1] https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
And stupid sites block
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.
The Networking as expected.
[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:
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.