Wednesday, September 18, 2024

macOS Firewall Regressions in Sequoia

Will Dormann:

[Running] nslookup clearly causes a DNS request and a response to go over the wire, but nslookup eventually gives up thinking that no servers could be reached.

[…]

So if I turn off the macOS firewall, this all works fine. 🤔

[…]

Problem #1: “Block incoming connections” includes DNS responses is new as of macOS Sequoia. Prior to macOS 15 Sequoia “Block incoming connections” meant “Don’t poke a hole in my firewall for this”. Starting with Sequoia, this also includes “Don’t allow responses to DNS requests”, which is clearly a bug in the macOS stateful firewall. Any response to a request that I initiate should be allowed in.

Problem #2: The macOS GUI for firewall rules being disconnected from the existing rules (e.g. cannot change some) is apparently an artifact of macOS switching underlying storage for the firewall rules at some point. And the GUI apparently is only hooked up to the old storage. If you’ve had a Mac for a while, you’ll probably get bitten by this.

Wacław Jacek:

It seems the OS firewall can sometimes start blocking access to web browsing after upgrading to macOS Sequoia. At least this was the case for me and some folks on Reddit.

Going to the firewall settings screen, there can be no way to toggle access for the browser.

Ivo Damjanović:

I have an issue with the firewall too. It does not accept incoming SSH connections. But they are allowed. I think this is a bug. I can tell you how to edit the entry list. You are able to edit some of them because the UI uses an old firewall rule storage. You can not edit the rules that use the new storage. You may edit them with sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps.

I’m also hearing that firewall and other security and networking settings were silently reverted by the Sequoia update.

See also: MacRumors, Reddit, ESET.

Previously:

Update (2024-09-20): Arin Waichulis:

However, according to TechCrunch, it now appears to be disrupting security tools made by CrowdStrike, SentinelOne, and Microsoft. Social media users are also reporting connection failures with third-party VPNs.

[…]

Patrick Wardle, a long-time iOS and Mac security expert and founder of the Objective-See Foundation, expressed his frustration, noting that Apple’s lack of thorough testing is to blame.

“As a developer of macOS security tools, its incredibly frustrating to time and time again have to deal with (understandably) upset users (understandably) blaming your tools for breaking their Macs, when in reality it was Apple’s fault all along,” Wardle told 9to5Mac.

Commenters on that article are blaming developers for not testing during the macOS beta period, but Wardle shows that the issue had been reported to Apple prior to the RC.

Update (2024-09-25): Brandon Vigliarolo:

Something’s wrong with macOS Sequoia, and it’s breaking security software installed on some updated Apple systems.

[…]

Both Microsoft and ESET have posted bulletins about networking problems in macOS 15, and both report different fixes for their respective problems as well.

[…]

Speaking to The Register, Wardle told us he’d heard from some of the larger vendors he’s spoken to that Apple has acknowledged some unintended changes that it was working on fixing, but said he wasn’t sure if that meant the issue was at the firewall or lower-level networking components.

Via Sam Rowlands:

Some users of my software have reported that the auto update system can fail also, in the networking portion of the code.

17 Comments RSS · Twitter · Mastodon


Is the Firewall really worth using. It seems that it is one app that Apple keeps overlooking and needs work, desperately. Is the third party Firewall doing a better job?


There are issues at the moment with VPN apps (like Mullvad) blocking access to essential services like iMessage and FaceTime. Not all VPN apps are affected — the word on the street is that the Wireguard app is not, for example — but many apps that do fancy networking, DNS, or firewalling stuff to implement split networking or kill-switches seem to be. (Mullvad for example creates dynamic firewall rules to prevent leaks.)

Did Apple change some low-level frameworks at the last minute or were VPN companies asleep at the wheel during the beta period? In any case, there seems to be a cluster of networking issues with Sequoia, which did not come to light over the summer…

https://github.com/mullvad/mullvadvpn-app/issues/6521


This is just the worst. Unbelievable to eff up such a basic component. When will Apple finally learn to not release a major OS version every year and instead invest a few years in getting the basics right again? (Spoiler: never.)


> I’m also hearing that firewall and other security and networking settings were silently reverted by the Sequoia update.

There is definitely something that went wrong – I believe very late in the beta process – with Local Network access:

- I just filed FB15176762 - UI for Local Network settings in Sequoia 15.0 24A335 seem disconnected from behavior (it can be read at https://iosdev.space/@cdf1982/113164866859627559, sadly Mastodon didn't let me post the video: basically, after deleting and rebooting an app, the controls in Local Network were still there, duplicated, and toggling one triggered the other, or sometimes both, and in a case it didn't allow to disable a deleted app...)

- JD Gadina filed FB15174703 - macOS Sequoia Local Network permissions only apply to applications in the /Applications directory (https://mastodon.social/@macmade/113163757345604170), which I could also reproduce.


I got bit by this as well. Somehow my browser got blocked in the MacOS firewall and all of a sudden I couldn't resolve DNS. Also, it looks like adding and removing applications from the firewall settings is broken both in the System Settings UI and on the command line via /usr/libexec/ApplicationFirewall/socketfilterfw.

Only thing to do for now is turn the OS firewall off. I'd recommend that anyone who needs a firewall in MacOS 15 rely on LittleSnitch.


@Fred McCann — I emailed the good people at Objective Development asking for their views on using Little Snitch instead of the macOS firewall and — much to their credit and contrary to my possibly cynical expectations — they recommended using both if possible, noting that Little Snitch operates at a much higher level in the stack and that it too could be affected by bugs or holes in the Apple APIs that underpin its network filter. In other words, they advocated a defence-in-depth approach, which makes perfect sense from a security perspective. Of course, the macOS firewall blocking all Internet access does seem to take “defence-in-depth” a smidge too far…


"There are issues at the moment with VPN apps (like Mullvad) blocking access to essential services like iMessage and FaceTime."

Is there a known workaround for this? I'm running into this with both OpenVPN Connect and Viscosity (both based on OpenVPN). I do not have the macOS firewall enabled.


I dunno, this is seemingly just Apple's increasingly typical approach to QA.

As it happens I just bought Little Snitch, as well as Vallum for contrast. I still think that in general host-based firewalls, especially application firewalls, are a bit of a red herring, but I acknowledge that it's useful to have the control that at least the OS in theory enables. I would have been perfectly happy with a noninteractive CLI toolfor accessing a transparency log, however. The macOS Firewall was weak sauce, so I hope that somehow Apple are planning more features as well as fixes. Guess we'll see.


I experienced some weirdness with the Murus firewall when upgrading to 15.0 Sequoia; the Sonoma 14.7 security update which was released the same day also experienced firewall issues. I had to reset Murus and reload my rule set. Vallum is not compatible but the beta has already gone public. No issues at all with iOS 18.

All 5 of my VPNs still work on macOS and iOS, and I haven't noticed any lasting networking issues. My guess is that some of those more advanced products muck about deeper in the system than Apple wants them to go for security reasons. From what I've read, a lot of the issues like boot loops, etc, are related to system extensions, which I avoid like the plague. Something tells me these issues people are having are a feature not a bug.

"“I get it, that writing bug-free software is challenging, but maybe if Apple spent less time and money on marketing, and more time on actually testing their software, we’d all be better off!” Wardle told TechCrunch." Also, if these products are so critical to their customers, they should have advised them not to upgrade immediately and wait for the 15.1 update.

I love this quote. So these clowns over CrowdStrike, SentinelOne, Microsoft, etc, never bothered to test their products with the developer betas to insure they are compliant with Apple's new release?


> So these clowns over CrowdStrike, SentinelOne, Microsoft, etc, never bothered to test their products with the developer betas to insure they are compliant with Apple's new release?

@Jes: by all means, I'm not the one to defend those companies, but my personal experience in the last 3 years is that testing during the summer and having compatibility on day one are very different things: Apple is in the habit of changing things up to the last beta.
For instance, the issues with Local Network I wrote about above never showed up during the Summer (and I installed each one of the 8 betas, starting on WWDC night), and yet they managed to surprise us with bugs introduced at the last minute.
Add the total lack of documentation about the changes in the Firewall and Local Network access, and the recommendation to postpone updates is sad but very sensible, in my opinion, and it has much less to do with the work of third-party developers than of Apple quality assurance.


Is there any workaround for this issue. corporate machines do not have direct access to disable the firewall


Wardle: "I get it, that writing bug-free software is challenging, but maybe if Apple spent less time and money on marketing, and more time on actually testing their software, we’d all be better off!"

Yes, get those marketing people back to their code testing! :-)

But I agree that Apple needs to be much (MUCH) better with release notes, especially for developers. And maybe changes to core functionality should not be allowed after the last beta before RC.


For me, the typ provided by Wacław Jacek fixed my issues. For me, this update broke my email apps — now fixed! Just a quick question: Do the apps added via the CLI option --add overrule the "Block all incoming connections" setting. Because, in my opinion, this seems to be the case. The question is whether this is intentional or not. If we trust the GUI settings, this might not be intentional. Do you have any more insights on this?


After upgrading to macOS Sequoia, firewall blocks the following 3 processes completely:

1) sudo port update --all

2) sudo tlmgr selfupdate

3) sudo port upgrade outdated

Appreciate very much if anyone can tell me how fix them.


I dunno, I just wouldn't trust the macOS built-in firewall at this point, seeing as how the GUI is clearly broken. Using extensions doesn't do quite the same thing but it is good enough if you have a compatible firewall that manages incoming connections. Little Snitch and Vallum have been updated for Sequoia now. Murus can be used to tighten up the ALF if you want more control however it uses pf to implement the filtering, so you can't use it to track processes as such, but it is very nice and I could plausibly use this to implement a router.


Yes, the firewall seems completely broken. Some apps, like Terminal.app, appear in the list out of nowhere when using iTerm, along with strange unknown services, even though it's set to block all mode.


Several of the issues I had with firewall interrupting SSH connections and VPN seem to have been fixed in 15.1.

Leave a Comment