How can I get Apple to address the vulnerability in Sonoma to a fork bomb?

You can't. It's an inherent problem in any OS that allows processes to create new processes (whether by forking themselves or not). The potential solutions to that are also in the same Wikipedia page, like setting limits on the number of processes a user can own.

And of course, anyone in a position to detonate a fork bomb on a system already has shell access to the system...so if they are detonating a fork bomb, I would have to wonder what else they did - or what data they stole - before doing something whose only real value is to force a system crash and *maybe* hide their tracks a bit.

zslg01 wrote:

how can I get Apple to address the vulnerability in Sonoma to a fork bomb? A simple one like in the Wikipedia page will crash MacOS

The “vulnerability” here is that any app — whether a shell script or any other language — can be coded in such a way to consume all available system resources; into a denial of service.

If you want to reduce that exposure, set ulimit -u lower, though there will always be opportunities for denial-of-service shenanigans.

I am aware of operating systems that implement process resource quotas and scheduler algorithms that can reduce the exposure to these denials-of-service, though someone then has to monitor and manage those quotas for the current and future app and system environments, and deal with cases where those quotas inevitably block legitimate operations.

This whole approach is closer to batch-oriented programming for those that are familiar with that, where numbers of processors and processes and process priority and other system resources can be constrained.

And if somebody has decent scheduling priority and enough processes to fill all the cores, things can still get sluggish.

And as sagely mentioned above, if somebody is sending a fork bomb your way, or some other denial-of-service, you likely have a security problem or a staff issue. Or quite possibly, both.

This all short of locking down macOS to approved apps, or of switching to iPad or iPhone and reviewed apps, or similar techniques, that is.

zslg01 wrote:

Ok enough time spent on this - a simple shell script or C program can crash MacOS … there obviously isn’t much more than that.

Yep.

As can an app that writes one byte in a loop.

Or as can a zip bomb.

Or a reflection attack, involving any number of internal or external services.

Mach port exhaustion should be familiar to anyone that has (ab)used Mach too, of course.

q.v.: https://opensource.apple.com/source/CF/CF-744.12/CFRunLoop.c.auto.html

__THE_SYSTEM_HAS_NO_PORTS_AVAILABLE__

Blocking denials-of-service from authorized users means setting up resource quotas and jails, or maybe using guests or containers, depending on which shared resource is being depleted.

zslg01 wrote:

Thanks - I figured that - having had a lot of *nix experience. Long ago, far away it used to be harder to crash a Mach based system - something about internal queues filling up and slowly going into a wait. Sonoma on a M2 Ultra dies before you can even see what process is the culprit.

I keep forgetting MacOS is not a server OS, unlike Snow Leopard for example where ulimit was set much lower by default. Oh well - guess I see if I can get FreeBSD up and running.

macOS kernel is XNU, which is a mix of BSD and Mach.

Other denial-of-service messes exist, not the least of which are zip bombs.

FreeBSD rctl inside a jail will probably be able to ameliorate the effects of a fork or zip bomb.

On FreeBSD, see man tuning(7), man rtcl(8), etc.

While my macOS and FreeBSD requirements will undoubtedly differ, I’m still not intending to allow arbitrary code execution on the local boxes either.

I don’t know if FreeBSD boots natively on Apple silicon. Asahi Linux was furthest along there, when last I checked.

And AFAICR, Mac OS X 10.6 both server and client will react badly to fork bombs, too. And most systems this side of those targeting upper-end TCSEC or more recently upper-end Common Criteria EAL, or otherwise specifically tuned and hardened, are also likely going to react badly.

Even the upper-end TCSEC or Common Criteria systems wouldn't handle fork bombs well - the CIA triangle was always weighted more towards "C" then "I" and then "A", and fork bombs would be an edge case concerns on isolated system-high networks (or, again, there are bigger problems to worry about if that edge case is triggered).