Fixing Vulnerability 0.0.0.0 in Chrome, Firefox, and Safari • The Register

A security bug that has been going on for years in nearly all web browsers — Chromium-based browsers, including Microsoft Edge and Google Chrome, and WebKit browsers like Apple’s Safari and Mozilla’s Firefox — has been addressed.

Criminals can and have exploited it to gain access to software services they shouldn’t have access to. The vulnerability affects the above-mentioned browsers on macOS and Linux — and possibly other browsers — but at least not Windows.

A company called Oligo Security uncovered the vulnerability this month and named it 0.0.0.0 Day because it involves the IPv4 address 0.0.0.0. Attackers have apparently been abusing the vulnerability since at least the late 2000s — based on Mozilla Bugzilla string From that era, which is still listed as open.

According to Oligo, each of the three browser teams has promised to block all access to 0.0.0.0, and they have also promised to implement their own mitigation measures to close the localhost vulnerability.

The problem is quite simple: if you open a malicious web page in a vulnerable browser on a vulnerable operating system, that page can send requests to 0.0.0.0 and a port of its choosing. If you have other servers or services running locally on your machine on that port, those requests will go there.

So, if you have some service running on your macOS or Linux workstation on port 11223, and you assume that no one can access it because it’s behind your firewall, and your big browser is blocking external requests to localhost, think again because that browser will forward a 0.0.0.0:11223 request by a malicious page you’re visiting to your service.

It’s a very remote possibility in terms of practical exploitation – but you wouldn’t want to discover that some site has accidentally accessed your local endpoint. In fact, it’s funny that this is going to happen in 2024.

There are supposed to be security mechanisms in place to prevent external sites from accessing your localhost in this way. Specifically, Cross-Origin Resource Sharing (CORS) Specifications, then the latest Private Network Access (PNA)which browsers use to distinguish between public and non-public networks, and enhances CORS by restricting the ability of external sites to communicate with servers on private networks and hosting devices.

However, the Oligo team was able to bypass PNA. The researchers set up a fake HTTP server running at 127.0.0.1, also known as localhost, on port 8080, and were then able to access it from an external public website using JavaScript, by sending a request to 0.0.0.0:8080.

“This means that public sites can access any open port on your host, without being able to see the response,” said Olejo security researcher Avi Lomelsky. Reported.

In response, Chrome will: roadblock Reaching 0.0.0.0 starting with Chromium 128, Google will roll out this change gradually to be completed by Chrome 133. Apple has Changes To its open source WebKit software that blocks access to 0.0.0.0.

Mozilla does not have an immediate solution, and has not implemented PNA in Firefox. According to Olgio, Mozilla has It changes Fetch specification (RFC) to block 0.0.0.0 after it is reported.

A Mozilla spokesperson sent The record The following statement via email:

According to Oligo, this research makes a strong case in favor of PNA.

“Until PNA is fully released, public websites can send HTTP requests using Javascript to successfully access services on the local network,” Lomelski wrote. “For this to change, we need to standardize PNA, and we need browsers to implement PNA according to this standard.”