The 0.0.0.0 kerfuffle
In the beginning, the web platform allowed websites to navigate to, submit forms
to, and load resources, such as images or scripts, from any other website. For
example, in the original design of the web, website1.test could load and display
an image from website2.test. The image load could even be authenticated via, for
example, cookies. website1.test would not, however, be able to directly read the
response.
In retrospect, this was perhaps not the best decision. It created a new class of attacks, cross-site request forgery, and, more generally, it ran afoul of some servers’ assumptions that they could only be contacted by devices on the same network. For example, an application running on an intranet might allow arbitrary state changes via POST requests, and not do any authentication or authorization on those requests, assuming that only trusted devices on the same intranet can send those requests. This is an incorrect assumption which any website can abuse.
Over time, the web platform evolved and gave websites more power to trigger requests to other websites – for example, XMLHttpRequest. The designers of these features tried to avoid expanding the capabilities of malicious websites to exploit vulnerable servers which don’t assume that the open web can send them arbitrary requests. These vulnerable servers expect, at most, to be contacted with a limited set of HTTP requests such as those that can be triggered by an image load or a form submission. Therefore, web platforms designers introduced the idea of CORS (cross-origin resource sharing) preflight requests: special HTTP requests that are designed to ask permission from servers to send them more complex requests from other origins. One website can send a so-called simple request to another website without a CORS preflight, but for a non-simple request, the destination server must respond affirmatively to a preflight request before the browser will send the non-simple request.
(CORS also includes mechanisms for servers to loosen the same-origin policy by allowing cross-origin requestors to read the bodies of their responses, but that’s mostly irrelevant to this post.)
More recently, a spate of high-profile vulnerabilities and attacks made it clear
that even simple cross-origin requests can cause real-world harm. Simple
requests – i.e., a request that could be triggered from one website to another
by “legacy” web behavior like an img tag or a form submission – can often be
used to exploit real servers on private networks or local hosts, which don’t
expect to receive even simple requests from the public web.
Thus was born the Private Network Access project. Private Network Access aimed to introduce a number of restrictions to prevent malicious public websites from sending requests to devices on the private network, without those devices explicitly opting in via CORS-style preflight requests. Private Network Access has been in development for several years now and has proven to be a difficult set of restrictions to roll out in practice, due to compatibility challenges.
In the past few months, some researchers discovered a popular AI-related application that runs a local server to receive commands, which can be exploited by HTTP requests from websites. This was framed and picked up in the press as a browser vulnerability, but in fact this is yet another example of a vulnerable application incorrectly relying on network position for authorization. It’s not a new vulnerability that a malicious website can cause a browser to send requests to the local server – that’s been the design of the web since the beginning, and while browsers have been trying to restrict this behavior, that restriction has not yet been successfully shipped.
The researchers did (re-)identify a legitimate browser-related issue: the Private Network Access draft specification neglected to designate 0.0.0.0 as an address on the private network or local host. In other words, addressing a malicious request to 0.0.0.0 would have been a loophole in the restrictions introduced by Private Network Access, had those restrictions already been rolled out.
In other words, the 0.0.0.0 kerfuffle was not a new browser vulnerability and it’s misleading to frame it as such. Instead, it would be better framed as a loophole in an upcoming security measure that browsers have been working to deploy, but have not yet deployed.