Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Apple to Address '0.0.0.0' Security Vulnerability in Safari 18

MacRumors

MacRumors

macrumors bot
Original poster
Apr 12, 2001
68,560
39,410


Apple plans to block websites from attempting to send malicious requests to the IP address 0.0.0.0 on macOS Sequoia, according to Forbes. The means the change will be part of Safari 18, which will also be available for macOS Sonoma and macOS Ventura.

safari-icon-blue-banner.jpeg

This decision comes after researchers from Israeli cybersecurity startup Oligo Security said they discovered a zero-day security vulnerability that allows a malicious actor to access private data on a user's internal private network. The researchers will present their findings this weekend at the DEF CON hacking conference in Las Vegas.

"Exploiting 0.0.0.0-day can let the attacker access the internal private network of the victim, opening a wide range of attack vectors," said Avi Lumelsky, a researcher at Oligo Security.

The researchers responsibly disclosed the vulnerability to Apple, Google, and Mozilla. More details are available on the AppSec Village website.

macOS Sequoia and Safari 18 are currently in beta and will be widely released later this year.

Article Link: Apple to Address '0.0.0.0' Security Vulnerability in Safari 18
 
Article Link
https://www.macrumors.com/2024/08/07/safari-18-to-block-0000-security-vulnerability/
Last edited:
  • Like
Reactions: RandomDSdevel
Not to worry, everyone, because Apple Support has the fix at the ready for this issue that they have never heard about, so it can’t be affecting customers:

1. Restart your device
2. Force restart your device
3. Reset network settings
4. Erase and reinstall, setting-up as new
5. RTA to Engineering
6. Engineering will request logs, with Mail logging enabled just to be safe
7. Within 48 hr, Engineering will let you know that this is a known issue, to keep your device up to date, and no further troubleshooting will be provided
 
  • Haha
  • Like
Reactions: swrobel, Shad0wLandsUK, adrianjagielak and 17 others
I hope the remediation for this exploit doesn't impact DNS-based ad blockers like Pi-hole which currently use the 0.0.0.0 address as the mechanism for blocking traffic to blacklisted hostnames.

Also, "Reader mode" in Safari bypasses the subscription nag on the linked article.
 
  • Like
Reactions: Frurro, mhnd, haruhiko and 2 others
I wonder what the deal really is. The 0.0.0.0 address should be rejected by the OS's network stack. According to RF 1122 (from 1989), section 3213, the all-zeros address (that is, network zero, host zero) means "this host on this network" and goes on to say that it should not be used, except for specific circumstances:

(a) { 0, 0 }
This host on this network. MUST NOT be sent, except as
a source address as part of an initialization procedure
by which the host learns its own IP address.

See also Section 3.3.6 for a non-standard use of {0,0}.
Click to expand...

Section 3.3.6 discusses broadcast addresses and states that a non-standard implementation (specifically citing BSD 4.2, but not 4.3) might use zero instead of -1 for the network/subnet/host fields of a broadcast packet and that hosts should accept incoming packets as such, making 0.0.0.0 equivalent to 255.255.255.255.

So the question remains: what does Apple need to fix? Any code trying to send a packet to/from address 0.0.0.0 should just get an error back from the network stack. And given the extreme age of systems that might use it as a broadcast address, the stack should probably reject packets from the network that use it as a destination unless the system is explicitly configured to allow them.

And if macOS's stack is not not discarding packets addressed to 0.0.0.0 and is not treating them identically to 255.255.255.255, well, then they've got a bug that should be fixed whether or not there's an exploit.
 
  • Like
Reactions: dreckly, rehkram, Frurro and 13 others
Nugget said:
I hope the remediation for this exploit doesn't impact DNS-based ad blockers like Pi-hole which currently use the 0.0.0.0 address as the mechanism for blocking traffic to blacklisted hostnames.

Also, "Reader mode" in Safari bypasses the subscription nag on the linked article.
Click to expand...
I do not think this should affect pi-hole. pi-hole uses 0.0.0.0 as a null address that should be rejected by the OS. https://docs.pi-hole.net/ftldns/blockingmode/
 
  • Like
Reactions: centauratlas, MasterControlProgram, austinmm6 and 1 other person
The description is vague, but I figure the following is going on:

Some app on the local machine is running a web server. This is either a developer running a dev build of a website locally or another software that uses HTTP internally (more than you think).

Normally such a server is never reachable from the outside. But Javascript on a website is not outside, it's running locally, so it can access these local web servers. And if they don't require authentication (e.g. maybe because the dev hasn't implemented it yet, or because security relies on it not being reachable from the outside), the Javascript can use the local web server to do nasty things, including accessing the users data.

But it's somewhat of an old hat. Some people claim it's "working as designed". Safari normally blocks such local requests, but Chrome didn't last time I checked. (It's a major reason I'm not using Chrome.) But I guess they figured out a way around Safari's block, which is what they probably reported to Apple.
 
  • Like
Reactions: Frurro, Populus, MasterControlProgram and 1 other person
breenmask said:
demonstrating the vulnerability before Apple releases a fix for all...?
Click to expand...
The MacRumors story says they already " responsibly disclosed the vulnerability to Apple, Google, and Mozilla. More details are available on the AppSec Village website." Not their fault apple is working so slow.
 
  • Like
Reactions: centauratlas
foobarbaz said:
The description is vague, but I figure the following is going on:

...
But I guess they figured out a way around Safari's block, which is what they probably reported to Apple.
Click to expand...

The browsers enable external websites to communicate with (and potentially exploit) software that runs locally on MacOS and Linux. (Not Windows). Public websites are able to communicate with services running on the local network (localhost) and potentially execute arbitrary code on the visitor’s host by using the address 0.0.0.0. as you said if the services are open then any bugs there are exploitable.
 
olavsu1 said:
Why should I hammer my own server services?
Click to expand...
Presumably, you don't have the relevant ports open, since 0.0.0.0 would find them too. IOW, they're equivalent.

But that raises a question. How is 0.0.0.0 treated differently than 127.0.0.1? That is, what can an attacker do with 0.0.0.0 that they can't do with the traditional loopback?
 
Confused-User said:
Presumably, you don't have the relevant ports open, since 0.0.0.0 would find them too. IOW, they're equivalent.

But that raises a question. How is 0.0.0.0 treated differently than 127.0.0.1? That is, what can an attacker do with 0.0.0.0 that they can't do with the traditional loopback?
Click to expand...

According to the knowledge so far, 0.0.0.0 is an error, that does not lead nowhere, but a black hole: all incoming stuff -> /dev/null. but using 127.0.0.1 you are specifically pointing at your own host.

If 0.0.0.0 somehow resolves usefully to attacker, this is a problem

This means that an additional box must be placed on the LAN, which sends incoming correspondence without a reply -> /dev/null

//will come be thing in which free software is better than proprietary software.
 
Last edited:
olavsu1 said:
According to the knowledge so far, 0.0.0.0 is an error, that does not lead nowhere, but a black hole: all incoming stuff -> /dev/null. but using 127.0.0.1 you are specifically pointing at your own host.

If 0.0.0.0 somehow resolves usefully to attacker, this is a problem

This means that an additional box must be placed on the LAN, which sends incoming correspondence without a reply -> /dev/null

//will come be thing in which free software is better than proprietary software.
Click to expand...
Your answer doesn't make any sense, and is provably wrong. 0.0.0.0 was never like /dev/null.

This is what safari says when I try a 0.0.0.0 URL:
Safari can't open the page "https://0.0.0.0/index.html" because Safari can't connect to the server "0.0.0.0".

It is presumably making standard calls to the OS (socket()... connect()...) through a higher-level NSWhatever(), so this is an expected result. Chrome, Firefox, etc., will all do the same (perhaps sticking with the standard Unix calls, not NSWhatever()).

If I start a listener on port 44444: "nc -4k -l 44444"
...then if I use Safari to go to http://127.0.0.1:44444/index.html, I will see the GET from Safari come to my listener.

You know what I see if I instead go to http://0.0.0.0:44444/index.html? *THE EXACT SAME THING*. Well, except the Host: header now says "0.0.0.0" instead of "127.0.0.1".

You can test this yourself on your Mac.

Anywhere an attacker can specify 0.0.0.0 in a malicious web page, they can also specify 127.0.0.1. So I repeat, what is special about 0.0.0.0? How does it enable an attack vector that doesn't already exist with 127.0.0.1 (or more generically, "localhost")?

Also, your "additional box on the LAN" is useless. It'll never see traffic sourced on client machines going to 0.0.0.0. Unless you mean you want to use it as a filter before traffic ever gets to the client, which will not play well with https. (Or, I suppose, as a proxy. But that's all well understood tech already, and use of all-0 instead of loopback changes nothing there.)
 
Last edited:
Confused-User said:
Anywhere an attacker can specify 0.0.0.0 in a malicious web page, they can also specify 127.0.0.1. So I repeat, what is special about 0.0.0.0? How does it enable an attack vector that doesn't already exist with 127.0.0.1 (or more generically, "localhost")?
Click to expand...
I share your confusion about the nature of this exploit. The only thing I can come up with is that maybe 0.0.0.0 allows bypassing CORS protections in a way that 127.0.0.1 does not, but that's complete speculation on my part. I hope once this does get patched in the affected browsers we'll learn more detail about its mechanism.

Since they indicate that the fix lies in the browser and not the network stack, it's got to be something along those lines.
 
Confused-User said:
Also, your "additional box on the LAN" is useless. It'll never see traffic sourced on client machines going to 0.0.0.0.
Click to expand...

Ehh, after installing that box, we change the ip addresses 0.0.0.0 and 127.0.0.1 in the lines of the bad servers in our hosts file to the ip address of that box.

And who forbids us to put that box in between the router and the LAN? Nobody. It can and is done that way too.
 
olavsu1 said:
Ehh, after installing that box, we change the ip addresses 0.0.0.0 and 127.0.0.1 in the lines of the bad servers in our hosts file to the ip address of that box.
Click to expand...
Yikes. I'm glad you don't work on my networking or security teams.

Changing the loopback to be off-local is *insane* and probably will break a lot of things because the assumption that it's localhost is deeply baked into lots of code. It may not even work. Changing 0.0.0.0 is even more dicey as it's basically unused and therefore untested. Since it's supposed to be an old synonym for the broadcast host there's a decent chance network stacks won't handle that well either. And that assumes your magical box can even allow it as an interface address.

And who forbids us to put that box in between the router and the LAN? Nobody. It can and is done that way too.
Click to expand...
Sure. If you're willing to proxy all web access (or play really terrible games with certs). But if you're willing to do that you almost certainly already are. In which case, yes, dealing with this in the general case is... still not feasible, because how exactly do you think you're going to deal with javascript that generates the 0.0.0.0 on the fly?
 
  • Like
Reactions: xpxp2002, shamino and olavsu1
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back