Apple to Address '0.0.0.0' Security Vulnerability in Safari 18

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

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 ('https://datatracker.ietf.org/doc/html/rfc1122#section-3.3.6') for a non-standard use of {0,0}.

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.

If this vulnerability is as serious as it seems, in my humble opinion it should be adressed or, at least, mitigated, in the next security updates of Safari 17, and even on the upcoming security patch of iOS 16 and Monterey.

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.

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.

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.

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/