IIRC it didn't just have no release notes, it explicitly claimed not to contain security patches.
Although I may be misremembering or may have been misled by an ambiguous message. https://support.apple.com/en-us/HT201222 lists it as being a security update but "This update has no published CVE entries." (emphasis mine) implying some nasty but embargoed security issue.
I am an iOS and MacOS developer and have gotten my updates rejected for my release notes not being descriptive enough of what it changes. Yet Apple regularly gives exceptions to the big guys like Facebook, Uber etc apps and now themselves. Apple’s developer guidelines specifically warn developers to not put vague release notes but the rules often get partially applied.
Interesting tidbit about Chrome using POSIX_SPAWN_NP_CSM_ALL now. But I would point out that according to the open-source Chromium code base, these CPU security mitigation APIs offer process-wide protection rather than thread-based protection (commit message at https://source.chromium.org/chromium/chromium/src/+/46e23c81... )
The security improvement I want is that when I run ‘ps ax’ on a fresh install, I have reduced attack surface instead of dozens of random daemons hardwired into launchd like the one for classrooms(??), iCloud and photo sharing even when those features are disabled, etc.
This is a big issue - on Windows you can set services to not start up unless they are needed, and you can turn them off so they don't run at all.
On macOS, the launchd configuration seems to be hard-wired and protected by SIP; there's no easy way to disable random daemons for features like remote student device management - something that most users would not need or want. And as you note even if you disable the associated feature (e.g. in Preferences) its daemon can still run.
It's always annoying when you're not doing anything but your laptop heats up and turns on the fans because some stupid daemon has woken up and decided to re-scan the same files (such as game updates) for the 100th time.
Not to mention photoanalysisd, which burns large amounts of CPU for days/weeks and runs even if you disable the intrusive and obnoxious holiday events/memories features in Photos.
I'd be interested to hear from someone with deep security knowledge:
Some people have dismissed OpenBSD's mitigations as overhyped (i.e. - things like W^X are not the main problem, linux has long caught up, etc).
But now we see Apple adding precisely some of these mitigations.
Where does this leave such architectural countermeasures? Are there real gains from investing in such low-level things? Are they irrelevant in an age where many laptops still have ports that give direct DMA access, users are not savvy and sandboxes incomplete?
W^X is a good mitigation to prevent attackers from just spraying shellcode into a RWX heap. This is how most JIT engines used to be attacked, and many exploits continue to include WebAssembly just because Chrome will create a RWX arena for this. Many of the OpenBSD mitigations are actually a good idea, but some are fanciful junk. The posture that the team has towards pushing those latter ones is what generally makes people unhappy.
Also, do note that Apple silicon puts everything behind a DART (essentially an IOMMU). This is noted in the article:
> Device isolation was another M1-only feature, that uses the more powerful IOMMU of that platform to make sure hardware devices can only share memory with the operating system and not with each other. Cross-device memory sharing is a historical custom, based on a blind, unfounded trust in hardware.
macOS has enforced W^X in most cases for many years.
As for the two mitigations mentioned in the article:
NO_SMT seems to be equivalent to Linux's "core scheduling" feature, which landed recently [1]. This approach, involving disabling SMT (aka hyperthreading) for specific processes, is different from OpenBSD's more brute-force approach of disabling SMT systemwide; there are pros and cons to both approaches.
As for the other one, forcing VERW to be executed on every return from the kernel, both Linux and OpenBSD chose the brute-force approach of doing this for all processes by default; both added this feature in 2019 as part of the coordinated disclosure of the MDS vulnerability class. Apple is instead doing it on a per-thread basis. Again, pros and cons.
It’s clear that W^X isn’t “solving security”, but it’s not a bad idea just because it’s a low-hanging fruit. On Apple platforms, I think that it came to be as a natural consequence of the ability to toggle RX mappings to be RW without a syscall.
Almost all DMA-capable peripherals on Apple Silicon (including iDevices) are gated behind an IOMMU.
Note that, although it was published recently, this article covers macOS 11 (Big Sur) which released last year, not macOS 12 (Monterey) which is in beta.
This is a great write-up. Are Apple getting more secretive as I had heard they were trying to become more open regarding their security. This and not providing release notes [1]for 11.5.2 make me think otherwise
I was hoping the article would mention the recent "security improvement" that prevents daemons from using Bluetooth in Big Sur. I haven't seen anything from Apple (or anyone else) explaining how that improves security.
That hasn't been a trivial option for a while, userland W^X (DEP) was implemented across the board >15 years ago.
TFA seems to be confused about what Apple did with the M1, macOS has had W^X enabled across the board (for userland) on all supported 64b architectures since 10.5 (10.4 only had stack W^X).
> NO_SMT disables Simultaneous multithreading (SMT), the CPU feature better known under Intel’s trade name of “Hyper-Threading”. SMT allows a CPU core to execute two or more threads at the same time, for improved performance at the cost of contention for per-core resources, such as caches, TLBs etc.
> Letting multiple threads share invisible resources carries the risk of letting a malicious thread steal secrets from a “sibling” thread running on the same core—a risk that over the years has materialized into multiple attacks, like TLBleed, PortSmash, Fallout, ZombieLoad, RIDL. A straightforward mitigation for this entire family of attacks, past and future, is then to simply disable SMT, which is what NO_SMT does.
BAHAHA cperciva was right! It’s a decade later and people care now! Linus didn’t care at the time!
I’m on mobile otherwise I’d link to relevant refs, but it was an “I told you so” 10 years in the making. Maybe longer? When was cperciva’s cache stealing research?
Sounds good but a problem with Apple's latest releases are that a lot of its security features listen only to Apple and not to the user.
This doesn't concern most of the improvements mentioned in the article, those are purely technical improvements at a very low level. But the signed system volume for example (also mentioned), while a good idea, lacks a convenient way for the user to make changes to it. I'm not very happy leaving my security to a black box and just trusting the supplier implicitly. This is a supplier that introduced a "get root with blank password" bug and the "your password hint is your actual password" one. Sure, everyone makes mistakes, especially for that reason I'd want to have more access than they offer now.
macOS is becoming more and more like iOS, which is also way too closed in my opinion. More locks is always good but the user should have a key, not just the supplier.
On the other hand, Linux is getting better and better. And with the prevalence of web apps, the main obstacle to running non (MS | Apple) systems is getting smaller. With Linux, you can adjust the level of security you need and you keep the key. Security improvements appear also in BSDs, especially OpenBSD, but honestly I wouldn't recommend people used to macOS to switch to OpenBSD (yet).
You can always disable CSR/SIP generally. macOS is unlike iOS in that many security mitigations can be disabled. The fact that new M1 Macs let you side load a diff non-Apple in iOS should be the ultimate proof you need of this motivation to allow user control on Macs.
> signed system volume for example (also mentioned), while a good idea, lacks a convenient way for the user to make changes to it.
MacOS has no convenient way to know if changes are made by the user or malware. It is a feature, not a bug, for most users. Why would you need to change system volume anyway?
[+] [-] bangonkeyboard|4 years ago|reply
[+] [-] tgsovlerkhgsel|4 years ago|reply
Although I may be misremembering or may have been misled by an ambiguous message. https://support.apple.com/en-us/HT201222 lists it as being a security update but "This update has no published CVE entries." (emphasis mine) implying some nasty but embargoed security issue.
[+] [-] peakaboo|4 years ago|reply
Today you have to run Linux to control your computer yourself.
[+] [-] busymom0|4 years ago|reply
[+] [-] kccqzy|4 years ago|reply
Some more digging shows that Chrome started using a weaker version of CSM, TCSM (thread CSM I assume) two years ago in NaCl: https://source.chromium.org/chromium/_/chromium/native_clien...
Firefox of course uses TCSM too: https://hg.mozilla.org/mozilla-central/rev/cd1ccb74af7c And so does Safari: https://trac.webkit.org/changeset/244233/webkit
I hope this at least somewhat assuages the fears of people who prefer Firefox or Safari over Chrome.
[+] [-] user3939382|4 years ago|reply
[+] [-] musicale|4 years ago|reply
On macOS, the launchd configuration seems to be hard-wired and protected by SIP; there's no easy way to disable random daemons for features like remote student device management - something that most users would not need or want. And as you note even if you disable the associated feature (e.g. in Preferences) its daemon can still run.
It's always annoying when you're not doing anything but your laptop heats up and turns on the fans because some stupid daemon has woken up and decided to re-scan the same files (such as game updates) for the 100th time.
Not to mention photoanalysisd, which burns large amounts of CPU for days/weeks and runs even if you disable the intrusive and obnoxious holiday events/memories features in Photos.
[+] [-] walterbell|4 years ago|reply
[+] [-] uniqueuid|4 years ago|reply
Some people have dismissed OpenBSD's mitigations as overhyped (i.e. - things like W^X are not the main problem, linux has long caught up, etc).
But now we see Apple adding precisely some of these mitigations.
Where does this leave such architectural countermeasures? Are there real gains from investing in such low-level things? Are they irrelevant in an age where many laptops still have ports that give direct DMA access, users are not savvy and sandboxes incomplete?
[+] [-] saagarjha|4 years ago|reply
Also, do note that Apple silicon puts everything behind a DART (essentially an IOMMU). This is noted in the article:
> Device isolation was another M1-only feature, that uses the more powerful IOMMU of that platform to make sure hardware devices can only share memory with the operating system and not with each other. Cross-device memory sharing is a historical custom, based on a blind, unfounded trust in hardware.
[+] [-] comex|4 years ago|reply
macOS has enforced W^X in most cases for many years.
As for the two mitigations mentioned in the article:
NO_SMT seems to be equivalent to Linux's "core scheduling" feature, which landed recently [1]. This approach, involving disabling SMT (aka hyperthreading) for specific processes, is different from OpenBSD's more brute-force approach of disabling SMT systemwide; there are pros and cons to both approaches.
As for the other one, forcing VERW to be executed on every return from the kernel, both Linux and OpenBSD chose the brute-force approach of doing this for all processes by default; both added this feature in 2019 as part of the coordinated disclosure of the MDS vulnerability class. Apple is instead doing it on a per-thread basis. Again, pros and cons.
[1] https://lwn.net/Articles/861251/
[+] [-] fay59|4 years ago|reply
Almost all DMA-capable peripherals on Apple Silicon (including iDevices) are gated behind an IOMMU.
[+] [-] comex|4 years ago|reply
[+] [-] saagarjha|4 years ago|reply
Might as well mention it here: crytex is how you get code on the Security Research Device, rather than SSV.
[+] [-] beermonster|4 years ago|reply
https://eclecticlight.co/2021/08/15/last-week-on-my-mac-trus
[+] [-] faster|4 years ago|reply
[+] [-] sesuximo|4 years ago|reply
[+] [-] masklinn|4 years ago|reply
TFA seems to be confused about what Apple did with the M1, macOS has had W^X enabled across the board (for userland) on all supported 64b architectures since 10.5 (10.4 only had stack W^X).
[+] [-] no_time|4 years ago|reply
[+] [-] Toutouxc|4 years ago|reply
[+] [-] sillysaurusx|4 years ago|reply
> Letting multiple threads share invisible resources carries the risk of letting a malicious thread steal secrets from a “sibling” thread running on the same core—a risk that over the years has materialized into multiple attacks, like TLBleed, PortSmash, Fallout, ZombieLoad, RIDL. A straightforward mitigation for this entire family of attacks, past and future, is then to simply disable SMT, which is what NO_SMT does.
BAHAHA cperciva was right! It’s a decade later and people care now! Linus didn’t care at the time!
I’m on mobile otherwise I’d link to relevant refs, but it was an “I told you so” 10 years in the making. Maybe longer? When was cperciva’s cache stealing research?
[+] [-] gregsadetsky|4 years ago|reply
https://news.ycombinator.com/item?id=16082909
cperciva's paper from 2005 (linked above):
http://www.daemonology.net/papers/htt.pdf
[+] [-] mzs|4 years ago|reply
introduce memfd_secret system call to create "secret" memory areas
v11: * Drop support for uncached mappings
https://lwn.net/ml/linux-kernel/20201124092556.12009-1-rppt@...
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] GekkePrutser|4 years ago|reply
This doesn't concern most of the improvements mentioned in the article, those are purely technical improvements at a very low level. But the signed system volume for example (also mentioned), while a good idea, lacks a convenient way for the user to make changes to it. I'm not very happy leaving my security to a black box and just trusting the supplier implicitly. This is a supplier that introduced a "get root with blank password" bug and the "your password hint is your actual password" one. Sure, everyone makes mistakes, especially for that reason I'd want to have more access than they offer now.
macOS is becoming more and more like iOS, which is also way too closed in my opinion. More locks is always good but the user should have a key, not just the supplier.
[+] [-] hdjjhhvvhga|4 years ago|reply
[+] [-] azinman2|4 years ago|reply
[+] [-] nuker|4 years ago|reply
MacOS has no convenient way to know if changes are made by the user or malware. It is a feature, not a bug, for most users. Why would you need to change system volume anyway?
[+] [-] goodpoint|4 years ago|reply
That's the definition of backdoors.
[+] [-] throwawaymanbot|4 years ago|reply
[deleted]
[+] [-] thepangolino|4 years ago|reply
[deleted]
[+] [-] Scoundreller|4 years ago|reply
[deleted]
[+] [-] justinzollars|4 years ago|reply
[deleted]
[+] [-] darwingr|4 years ago|reply
[+] [-] azinman2|4 years ago|reply