Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5273.
Apple doesn’t release information about what security issues this update might add or change. This adds Yara definitions for MACOS.DOLITTLE.CT, MACOS.SHEEPSWAP.CT and MACOS.SOMA.CT using a new format of rule, with each rule given a UUID and listing SHA256 hashes of file size.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5273.
If you’ve upgraded to Sequoia and are still stuck at a version number of 0 or 5272, you can either leave macOS to catch up with this in its own good time, or you can force an update by typing into Terminal sudo xprotect update
then entering your admin password.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
It’s strange to think that, as we’re wondering whether and when to upgrade to Sequoia, Apple’s engineering teams are already at work on macOS 16. While they’re thinking out what we’ll chew over next summer, you may well be asking if you should upgrade to 15.0 next week, wait for the AI features coming in 15.1 next month, or leave your decision until 2025?
For those with Macs and iPhones that can both be upgraded, iPhone Mirroring is probably the most obviously attractive new feature. It completes the integration of Continuity, and could transform your workflows. Fortunately for such a key feature, it should work with all supported Macs, not just Apple silicon models. There’s one small and temporary disappointment, though, as drag and drop between Mac and iPhone isn’t expected in 15.0, but in an update “later this year”.
The new Passwords app should spare you from wanting to pay for a third-party password manager. This is much more than just shelling out the existing Passwords feature from Safari and System Settings, and at last gives full control over passkeys and other shared secrets in your Keychain in iCloud.
Although some see Sequoia’s new dislike for apps that aren’t notarized (or from the App Store) as an unnecessary burden, for most of us this will raise the bar against running malware and increase our margin of safety. It has been some time since any malicious software has been successfully notarized, and most of the current epidemic of stealers aren’t even signed with a Developer certificate. Instead, they usually prompt the user to open them using the existing Finder bypass, something that no longer works in Sequoia without explicitly and individually giving permission to that app in Privacy & Security settings.
It will be interesting to see how malware developers respond to this challenge, as trying to give the user detailed instructions as to how they can be run without being blocked by Gatekeeper should now arouse the suspicion of even the most careless and inattentive.
While we’re on the subject of security, remember that Sequoia is now the only version of macOS that gets full security updates over the coming year. While Sonoma and Ventura will still get some, if you want the lot then you’ll need to upgrade. Monterey, of course, now gets none at all. This gets more brutal when considering other bugs that aren’t relevant to security: those will only be fixed in Sequoia, not even in Sonoma.
For those who virtualise macOS on Apple silicon, support for Apple ID gives VMs access to iCloud Drive at last, although it stops short of enabling the App Store or its apps, so isn’t as useful as it should have been. There are two important restrictions to this:
Apple ID can only be used in a Sequoia guest running on a Sequoia host, and
the Sequoia VM has to be built from a Sequoia IPSW file, and can’t be upgraded from a Sonoma or earlier VM.
As long as your Mac stays with Sonoma, you won’t be able to use Apple ID in any of its VMs, including Sequoia. This still leaves us with the paradox that Apple wants us to buy and run apps from its App Store, but VMs are the one place where you can’t use them.
Among the less prominent improvements that have caught my attention are a timed messaging feature of Send Later in Messages, and a batch of improvements in Freeform. If you’ve come to like that relatively new app, you should find Sequoia worth the effort. I’ve also been impressed to see one of the oldest bugs remaining in the Finder has finally been addressed in macOS 15. I’ll be putting the bunting out in celebration after I’ve upgraded on Monday.
As with Sonoma, some of the most important new features haven’t been documented even for developers. Among those are changes to XProtect in terms of its updating and management, and speculation as to how that might affect its function. As I have explained, XProtect’s detection rules have grown enormously over the last few months, and it’s likely that Apple intends improving how XProtect can apply its Yara rules, and making their updating more efficient.
Finally, Sequoia is almost certainly going to be delivered as if it were an update, and won’t download its installer app unless you’re upgrading from a significantly older version of macOS, just as has happened in all recent macOS upgrades. Remember that upgrading macOS these days comes with a one-way ticket: changing your mind afterwards will cost you a lot of time and messing about to step back to Sonoma. However, accidental upgrades shouldn’t be feared. For instance, if you inadvertently click the Install all updates button in SilentKnight and want to reverse that for a macOS update, let the download complete, shut down, start up in Safe mode, wait a minute, then restart in normal mode.
Whatever you choose tomorrow, I hope it works well for you. And in case you’re wondering, if you’ve got an Apple silicon Mac, you’re going to love 15.1.
As threats to his personal safety have become graver, the world’s richest man has barricaded himself behind a phalanx of bodyguards that operates like a mini-Secret Service.
Apple silicon Macs are the first Apple computers to feature fully secure boot processes as one of their fundamental design goals. Although similar in some ways to those in Apple’s devices and in Intel Macs with T2 chips, there are substantial differences. Unlike T2 Macs, secure Boot in Apple silicon is maintained even when starting up from external storage, a feature completely unsupported by devices. Non-standard configurations are also available to give greater flexibility with reduced security modes, which are absent from devices. This article explains how to manage Secure Boot on Apple silicon Macs.
Full Security
By default, Apple silicon Macs start up in Full Security, the mode recommended by Apple for normal use. That requires:
Following pre-boot stages, a Signed System Volume (SSV) is loaded from its snapshot, with its seal intact and signature verified.
The only kernel extensions loaded during boot are those supplied by Apple in macOS. No third-party kernel extensions can be loaded.
System Integrity Protection (SIP) is fully enabled.
Because they run outside the privileged space of the kernel and its extensions, third-party system extensions and their relatives can be loaded and used fully.
Booting in Full Security applies full control and verification of all components from the Boot ROM, through the Low-Level Bootloader (LLB) and iBoot ‘firmware’, to the kernel and its extensions in the SSV. If any part of that sequence fails to verify, the boot process is halted and, depending on where the failure has occured, the Mac is either put into DFU or Recovery mode for the user to address the problem. This not only ensures robust security throughout, but it also guards against potential conflicts such as those arising with third-party kernel extensions, and unintentional corruption of any component.
Changing security
Control over boot security is applied using Startup Security Utility when booted in paired Recovery (except in Big Sur, as explained below). Access this by starting the Mac up into normal paired Recovery with a single long hold of the Power button. When the first screen has loaded, click the Options button, then from the Utilities menu select the Startup Security Utility command.
You will then be prompted to select the boot volume group whose security policy will be set. Note that in macOS 12.0.1 and later this must be the same as that for the paired Recovery being used.
By default that will already be in Full Security. Set the new policy as explained below, and click the OK button. To apply that policy, select the Restart command to exit Recovery and start up in normal user mode.
Startup Security Utility changes the LocalPolicy settings for that boot volume group; those are stored in the iSCPreboot volume on the hidden Apple_APFS_ISC container on the internal SSD of that Mac. Full details of LocalPolicy are given in Apple’s Platform Security Guide, and explained here.
Big Sur is a notable exception to the requirement to change security settings in the paired Recovery volume: it doesn’t have a paired Recovery volume, but boots into Recovery from a hidden container on its internal SSD, from where Startup Security Utility controls security settings for all mounted boot volume groups.
Fallback Recovery (frOS) is unable to change LocalPolicy, thus Startup Security Utility is unavailable when booted in frOS, its most distinctive feature.
Although the bputil command tool gives access to security settings, its use to modify them is hazardous, and shouldn’t be attempted unless you know what you’re doing and are prepared to have to restore that Mac in DFU mode. It is, though, sometimes useful as an aid to solving problems with LocalPolicy settings, as explained here.
Reduced Security
When reducing security settings, the only other option available is Reduced Security, which forms the gateway to Permissive Security as well. There are two other common reasons for selecting Reduced Security, though: to enable the loading of third-party kernel extensions, and to run older versions of macOS.
To enable the loading of third-party kernel extensions, Reduced Security must be set, and the upper checkbox ticked. Once this has been applied by a restart, installation and loading of the kernel extension can proceed using its installer and Privacy & Security settings. That doesn’t enable loading of the kext on demand, as in the past, as it has to be merged into a signed Auxiliary Kernel Collection, from where it can loaded during startup.
Although Apple states that Reduced Security is required to run older versions of macOS, that doesn’t appear to be required at present. Reduced Security differs from Full Security in that LLB and iBoot trust ‘global’ signatures that are bundled with macOS rather than using personalised signatures for iBoot and beyond. For many, this may appear to be an insignificant reduction compared with Full Security, although it does add the risks of loading third-party kexts when used for that purpose.
Permissive Security
Startup Security Utility doesn’t offer Permissive Security as an option until Reduced Security has been selected and an action has been taken to downgrade that to Permissive Security. The most likely reason for doing this is to partially or completely disable SIP using csrutil, and once that has been performed this third setting is shown in Startup Security Utility.
Just as with Reduced Security, this offers two further options in checkboxes, including that to enable the loading of third-party kernel extensions.
The main reason for using Permissive Security is to reduce SIP settings, and I have recently provided a guide to the controls available in csrutil. The normal sequence for changing those is to start up in paired Recovery, open Startup Security Utility, set that to Reduced Security and click on the OK button. Following that, open Terminal, run the appropriate csrutil command, then restart the Mac, which will automatically be in Permissive Security.
The security effects of Permissive Security are determined largely by changes made to SIP and other controls. Although signatures are still validated throughout the chain of boot stages, ‘global’ signatures are trusted for iBoot and beyond, as are boot objects signed locally by the Secure Enclave. At its most extensive, this allows the use of a fully untrusted kernel, such as a debug or custom version. The penalty is that some decryption keys are no longer available, and those restrict features available in macOS, such as Apple Pay, which is normally disabled.
Reversing Permissive Security requires fully enabling SIP using csrutil, undoing any other relevant security settings, then using Startup Security Utility to set a higher level of security. In some cases, that may entail installing a fresh macOS with its SSV. Apple also notes that, on Apple silicon Macs, SIP settings aren’t stored in NVRAM but in the LocalPolicy.
External Boot Volumes
With the notable exception of Big Sur, boot security settings are saved into the LocalPolicy for the boot volume group containing that paired Recovery system, although all LocalPolicy settings are saved to the internal SSD, never to an external disk. This relies on the concept of ownership, as explained here. This can bring its own problems, as explored here.
Summary
Unless there’s a good reason, leave boot volume groups in Apple silicon Macs in Full Security.
If your Mac needs to load a third-party kernel extension, run it in Reduced Security with those kernel extensions enabled.
Partially or completely disabling SIP requires Permissive Security, which brings significant penalties, and may require more extensive work to undo.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 145. The previous version was 142.
Apple doesn’t release information about what security issues this update might add or change. There are no changes in the number or names of its scanning modules, and Bastion rules also remain unchanged.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-145.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Over a series of three articles last week, I pored over thousands of log entries to examine how macOS Sonoma 14.6.1 checks applications it’s launching, under normal full security settings, with reduced security, and for known malware. This article draws together my conclusions from those tests run in virtual machines on an Apple silicon Mac.
Layered security
Like other security functions in macOS, app launch security is built in layers, including checks of
code-signing certificates (multiple times);
CDHashes, including their consistency, and against Apple’s database for notarized apps, and their revocation;
quarantine extended attributes, which normally trigger a user consent dialog, and may result in app translocation;
previous launch, in the LaunchServices database;
matches with Yara rules in XProtect’s data;
user consent to a first launch prompt dialog;
launch and other constraints.
Additional data may also be collected and stored in the provenance database that first appeared in Ventura.
Not all checks are performed on every launch of an app. At a minimum, for a notarized app that has been run only recently, these might consist of only local checks against CDHashes and with the app’s existing entry in the LaunchServices database. Checks are also modified by reducing security settings:
Disabling Gatekeeper checks doesn’t stop those checks from taking place, but apparently ignores some results, notably those obtained by XProtect. It doesn’t affect checks of CDHashes against Apple’s database.
Disabling SIP has more pervasive effects in largely disabling the com.apple.syspolicy sub-system, affecting several layers, although checks of CDHashes against Apple’s database are unaffected.
com.apple.syspolicy
In full security conditions, one sub-system dominates log entries concerning app launch security, com.apple.syspolicy. This is clearest in Gatekeeper and XProtect checks. Although the log entries that follow may appear bewildering, they are the best illustration of this point.
When launching a notarized app that hasn’t previously been run on that Mac and has a quarantine xattr, Gatekeeper and XProtect scans are reported in the following sequence of entries: com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>
com.apple.syspolicy.exec Skipping TCC check due to process: 692, 0, 692
com.apple.syspolicy.exec queueing up scan for code: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: (null)), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec starting work for scan for code: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: (null)), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec allowUI is YES, creating codeEval object: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: (null)), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec Adding default exception for team: <private>
com.apple.syspolicy.exec Registered app bundle for protection: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec GK performScan: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
com.apple.xprotect XProtectScan beginAnalysisWithResultsHandler continueOnError is set to 0
com.apple.xprotect XPAssessment performAnalysisOnFileImpl continueOnError set to 0
com.apple.xprotect Xprotect is performing a direct malware and dylib scan: <private>
Those checks later complete in entries such as: com.apple.syspolicy.exec GK Xprotect results: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), XPScan: 0,-7676743164328624005,2024-08-26 08:19:01 +0000,(null)
com.apple.syspolicy.exec GK scan complete: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), 4, 4, 0
com.apple.syspolicy.exec scan finished, waking up any waiters: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)
com.apple.syspolicy.exec App gets first launch prompt because responsibility: <private>, <private>
com.apple.syspolicy.exec GK evaluateScanResult: 0, PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist), 1, 0, 1, 0, 4, 4, 0
com.apple.syspolicy.exec GK eval - was allowed: 1, show prompt: 1
com.apple.syspolicy.exec Skipping TCC check due to process: 692, 0, 692
com.apple.syspolicy Found console users: <private>
com.apple.syspolicy.exec Prompt shown (5, 0), waiting for response: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)
When SIP has been disabled, there are precious few entries from com.apple.syspolicy or com.apple.syspolicy.exec. Instead, XProtect appears to be left to its own devices, and doesn’t fare well: com.apple.xprotect XPAssessment performAnalysisOnFileImpl continueOnError set to 0
com.apple.xprotect XprotectService Calling SecAssessmentCreate with URL <private>, context <private>
XprotectService SecTrustEvaluateIfNecessary
com.apple.xprotect XprotectService Bundle is not apple signed
com.apple.xprotect XprotectService Bundle size result: 18388222 (YES)
com.apple.xprotect XprotectService Always scan: YES
com.apple.xprotect XprotectService Starting malware scan for: <private>
kernel XprotectService [697] crossed memory high watermark (15 MB); EXC_RESOURCE
kernel Full corpse enqueued for XprotectService
com.apple.xnu memorystatus kernel kernel EXC_RESOURCE -> XprotectService[697] exceeded mem limit: ActiveSoft 15 MB (non-fatal)
ReportCrash event condition bump 0 -> 1
ReportCrash post-exception thread qos drop 21 -> 17
ReportCrash PID 697 exceeded the memory high watermark; Invoking ReportMemoryException with corpse.
There are no other entries referring to Gatekeeper or those checks. The effects of disabling SIP appear extensive and pervasive throughout several of the layers of app launch security.
CDHashes are central
With the adoption of notarization, apps run in macOS should now fall into one of five categories:
signed by Apple, either its own apps or those delivered through its App Store;
notarized by Apple, with its CDHashes added to Apple’s database;
signed (either with a Developer certificate, or ad hoc) locally, and not distributed over the internet, with its own unique CDHashes;
unwanted or malicious, with revoked CDHashes,
unrecognised, and potentially malicious.
These emphasise the importance of the online ‘notarization’ checks of CDHashes performed in all circumstances where macOS doesn’t have previous records of saved CDHashes for that code. Their primary purpose isn’t to validate notarization, but to identify code as known good, known bad, or unknown. When Apple’s security engineers identify new malware, its CDHashes can quickly be added to the database as being revoked, so ensuring that all subsequent checks of the same CDHash will be classified as revoked, for malicious code. This is a rapid response that should have no false positives, in which benign code is mistakenly identified as being malicious.
Typically, the checking sequence is reported in the log with: com.apple.syspolicy looking up ticket: <private>, 2, 1
com.apple.syspolicy cloudkit record fetch: <private>, <private>
com.apple.syspolicy cloudkit request cache info: <private>, max-age=300
com.apple.syspolicy CKTicketStore network reachability: 1, Mon Aug 26 09:15:45 2024
com.apple.syspolicy Inserting ticket: <private>
com.apple.syspolicy completing lookup: <private>, 0
[and so on with further lookups]
and those are among the only entries from com.apple.syspolicy seen when SIP is disabled.
When full security is enabled, those are completed with com.apple.syspolicy.exec GK evaluateScanResult: 0, PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist), 1, 0, 1, 0, 4, 4, 0
But when SIP is disabled, those don’t appear, and seem to be substituted by application of Security rule 11 instead.
The downside of CDHash checks is that their false negative rate can be alarmingly high. Change a single bit in the code being hashed, and the hash will amplify that change, and is completely different. Hence the importance of notarization to establish which CDHashes definitely aren’t from malicious code.
One threat to this system occurs when a user mistakenly blocks their Mac from connecting to Apple’s database using CloudKit, for example using a misconfigured software firewall. Without a suitable vulnerability, malicious software shouldn’t be able to use this approach to block a payload from being checked.
I don’t know whether any third-party security products use a similar checking mechanism with their own local or remote CDHash databases, but this appears to be a great advantage to the protection built into macOS.
Performance
Two of the checks performed with full security enabled are dependent on the size of the app being checked. Fully validating an app’s CDHashes against those in its signature or notarization ticket should benefit from hardware acceleration, particularly on Apple silicon, and can be tackled hierarchically. It appears unlikely to result in significant delays to launching an app.
XProtect scans are more likely to be responsible for observable delays in app launch times, though. With the recent growth in the number of Yara rules, and their length, scans performed after an app’s first launch are the most probable cause of large and complex app bundles requiring several seconds before the app can be run.
Summary
I have updated the flow chart I first proposed as a result of observations made of app launches in Sonoma 14.4.1:
If XProtect Remediator came of age in macOS Ventura, then it has been XProtect’s turn in Sonoma. Starting from version 2171 with 216 rules in under 3,000 lines in its Yara definitions, it emerged a year later in version 5272 with 347 rules in over 13,000 lines, although mercifully not after 3,100 versions.
I had always assumed that those Yara rules were compiled straightaway into something more tractable for checking executable code, but it seems that each time XProtect performs one of its ‘direct malware and dylib scans’, it first looks for a non-existent Yara file, then uses the rules in the XProtect.bundle, as it reports in the log: com.apple.xprotect Xprotect is performing a direct malware and dylib scan: <private>
com.apple.xprotect Rule path is not accessible: /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect2.yara
com.apple.xprotect Using XProtect rules location: /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara
Apparently, to cope with this explosive growth, and potentially support more frequent tweaks to its growing horde of Yara rules, macOS Sequoia is changing the way that XProtect’s data is updated and managed. A chance find by @L0Psec revealed how this has moved beyond those updates delivered by softwareupdate, and a new command toolxprotect handles this separately in CloudKit.
Last week’s update to XProtect’s Yara file was an experience those beta-testing Sequoia 15.0 or 15.1 must have found profoundly confusing, and I quickly became aware of reports that were changing by the minute.
When XProtect 5272 was first made available through softwareupdate, Sonoma and earlier systems found and installed it as usual, as did some running Sequoia betas. That updated the visible XProtect.bundle in CoreServices, but didn’t update XProtect according to its new xprotect command tool, which still reported the local version of XProtect as 5271. Without knowing how XProtect has changed, the user would most likely see this as a bug.
A little later, I saw reports of Sequoia installations apparently updating spontaneously via CloudKit, using its new mechanism, which did change the version reported by xprotect version.
At this stage, I had a 15.0 virtual machine that had updated ‘correctly’ via CloudKit, and its host 15.1 system that had updated its bundle via softwareupdate, but still wasn’t apparently running the new version afterwards. Those of us who didn’t experience a spontaneous CloudKit update were left in limbo. I had originally changed the version databases used by SilentKnight and Skint to show a correct version of 5272 for Sequoia, and hurriedly had to revert that to 5271 before I became inundated with complaints from those whose Macs hadn’t been able to update.
It then occurred to me to try using the xprotect command to force a CloudKit update on my 15.1 system. I first entered sudo xprotect check
only to be told that the version available was still 5271. But when I ran sudo xprotect update
a miracle happened, with the response Update succeeded: Activated update LocalUpdate[5272]
That command had convinced macOS to ‘activate’ the updated bundle in /Library/Apple/System/Library/CoreServices rather than waiting for it to become available from CloudKit, a feature not mentioned in its man page or usage info. I returned to my version databases to change them a third time, back to 5272.
Previous XProtect updates such as 5271 that were obtained through CloudKit are now identified by SystHist as XProtectCloudKitUpdate, while those obtained by softwareupdate and activated using the xprotect command appear as standard XProtectPlistConfigData, as they do in Sonoma and earlier.
With the release of Sequoia due later this month, the xprotect command tool and XProtect’s new CloudKit updates have already encountered troubled water. If Apple stays true to form and doesn’t mention a word about this change, or its effect on XProtect updates, many of the millions of new Sequoia users could end up falling behind. But as we’re not supposed to know what the latest version is, nor which is currently active on our Macs without taking to Terminal’s command line, maybe most won’t be allowed to notice.
I’d like to think that Apple will explain these changes to users, document its new command tool properly, and ensure that users know the current version of XProtect data, and can check whether their Mac is up to date without having to resort to Terminal or third-party products, perhaps in System Information. Will I be disappointed?
Although we won’t know for sure until Apple releases the upgrade to macOS Sequoia next month, once again it will probably be presented as an update rather than a macOS upgrade. This means that, instead of Software Update downloading a complete Sequoia installer app, if you do choose to upgrade, it will be run through Software Update the same way that it might have updated from 14.5 to 14.6.
Although this is more efficient, resulting in a smaller update and faster completion, it also opens up the possibility of human error: what if you accidentally opt to upgrade, or click on SilentKnight’s Install all updates button? This article explains how you can stop that upgrade from completing, and how you could upgrade using SilentKnight instead of Software Update.
Updating or upgrading macOS
When SilentKnight has completed checking for updates, if there’s a macOS update or upgrade available you can install it if you wish, from within SilentKnight. Although my personal preference is to hand macOS updates over to Software Update in Settings, SilentKnight should also work fine, up to a point.
To test this, I opened a VM running Sonoma 14.6, with XProtect 5270 and XPR 140. When it had found all three updates available, I clicked on the Install all updates button, just as I have always advised you not to! SilentKnight proceeded to download the macOS 14.6.1 update, but once that was complete it failed to install it. It then proceeded to download the XProtect and XPR updates, which it did successfully install on its own.
There was a vague notification that “Some updates could not be installed”, and the VM was left in 14.6, with XProtect and XPR correctly updated.
At that stage, Software Update stated the 14.6.1 update was available, offering a Restart Now button. When I clicked on that, the VM restarted and installed the 14.6.1 update successfully.
SilentKnight doesn’t provide the handy progress indicator that Software Update does, but just turns its busy spinner until the updates have finished. So you may still prefer to install macOS updates using Software Update. However, the end result should be just the same if you let SilentKnight do it, and finish off the installation using Software Update.
Downloading updates
Using another copy of the same VM running Sonoma 14.6 with outdated XProtect and XPR, I set SilentKnight’s settings to download but not install updates, then clicked the Download all updates button.
This left all the updates uninstalled, but there was no sign of them in the standard /Library/Updates folder as documented for softwareupdate. I looked high and low for those updates, but was unable to find them anywhere. I therefore recommend that you don’t use this option until someone has worked out where those downloaded updates are kept.
Unwanted macOS updates
If you click either the Install all updates or Download all updates button and one of the updates is for macOS, that will leave Software Update poised to complete the installation. If you didn’t want to install that macOS update, there is a way that you can now persuade Software Update to forget that it has been downloaded and is waiting, ready to install. This is most useful if you didn’t intend updating macOS, and now want to undo the process.
Shut your Mac down, then start it up in Safe mode. Leave it there for a minute or so, then restart it back into normal mode. Those uninstalled updates should now have been flushed, and Software Update is back to where it started.
Summary
You should now be able to install macOS updates using SilentKnight if you wish. When warned that some updates weren’t installed, open Software Update settings and complete the installation there using the Restart Now button.
Don’t use SilentKnight’s setting to only download but not install updates, as the downloaded updates can’t be found and used.
If you inadvertently click the Install all updates button and want to reverse that for a macOS update, let the download complete, shut down, start up in Safe mode, wait a minute, then restart in normal mode.
These apply to Apple silicon Macs, and are untested in Intel Macs, although there’s no reason to believe they should differ there.
Previous articles in this series described how macOS 14.6.1 security systems check the launch of apps when full security is in force on an Apple silicon Mac, and how those are changed by disabling SIP and Gatekeeper checks. Those have shown how checks are layered in accordance with the Security architecture of macOS, how different layers are invoked according to the status of an app (whether it’s quarantined, notarized, or has been run previously), and how extensive are the effects of disabling SIP. But no account of app security can be complete without examining how it protects against real malware, the aim of this article.
Methods
In these tests, I have again run four variants of the same 14.6.1 VM:
Full Security, with SIP and Gatekeeper/XProtect enabled;
Full Security, with Gatekeeper/XProtect disabled;
Permissive Security, with SIP disabled;
Permissive Security, with both SIP and Gatekeeper/XProtect disabled.
Samples of malicious software were obtained from the Objective-See Foundation’s collection. Three were chosen:
Atomic Stealer (AMOS, or Soma)
Genieo (InstallMac)
XCSSET
These were downloaded directly to each of the four VMs, when they were running in isolation in ViableS. Each was then unZipped and the contents moved to the Documents folder to try to ensure that their code wouldn’t be subjected to app translocation. Full log extracts were obtained from the Full Security VM for the first 5 seconds after launching Atomic Stealer and XCSSET; as the Genieo sample only installed its payload and didn’t launch its code, no log record was obtained for that. Log records weren’t obtained for the other three VMs, although the results of running the malicious payloads were observed for comparison against those of the Full Security VM.
Atomic Stealer
This was presented in a disk image that hadn’t been signed by a Developer certificate, and encouraged the user to try to bypass full Gatekeeper checks by opening the malicious payload CardGame.app using the Open command in the Finder’s contextual menu, a common strategy adopted by malware developers. This ruse was spotted early as a security exception with the code -67062, indicating that the disk image was unsigned, and that resulted in the app being translocated in its disk SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/s0/[…]/CardGame.app
This appears to be a less usual cause of translocation, although strictly within its rules.
AMFI quickly found a code signature issue, as reported by the kernel AMFI: '/private/var/folders/s0/[…]/CardGame.app/Contents/MacOS/My Go Application.app' has no CMS blob?
AMFI: '/private/var/folders/s0/[…]/CardGame.app/Contents/MacOS/My Go Application.app': Unrecoverable CT signature issue, bailing out.
AMFI: code signature validation failed.
Gatekeeper and XProtect scans followed, and the CDHashes were checked with Apple’s database over CloudKit. This discovered that one of the hashes had been revoked Notarization daemon found revoked hash: {length = 20, bytes = 0xe430ea6d59a70ac00c1b8552092f4de0bbb80232}
resulting in another security exception, this time of -66992, confirming that this code has been revoked. That check was then repeated with the same result.
Shortly after that, the XProtect scan was completed, finding a match for Atomic Stealer A GK Xprotect results: PST: (vuid: 11F66D42-5827-3465-A741-F434860C2862), (objid: 20), (team: (null)), (id: (null)), (bundle_id: (null)), XPScan: 11,-7676743164328624005,2024-08-27 07:31:10 +0000,MACOS.SOMA.A
and the decision was made to present the malware warning prompt present prompt: uid=501, conn=yes, type=Malware, op.ident=2F90B5EF-D483-43C7-BBD1-77E8EABF4D62, info.ident=8D56578B-833F-4629-86F0-4E0A8EDD7D49, info={<private>}
indicating that it’s game over for the CardGame app and its disk image.
This sample of Atomic Stealer was thus detected by two different and independent methods: its CDHash ‘notarization’ check revealing its revocation, and the XProtect scan matching it to the known signature of MACOS.SOMA.A. As the first of those is unaffected by disabling SIP or Gatekeeper, it’s not surprising that the sample was detected and blocked in each of the four VMs.
Genieo
This was presented in an Installer package as an Intel binary. This claimed to install “Apple software” and triggered a request to download and install Rosetta 2 if that wasn’t already available. The installer appeared to complete without eliciting any warnings, and it’s presumed that the malware would either have been detected later when there was an attempt to launch it, or in an XProtect Remediator scan.
All four VMs behaved identically, and there was no sign of recognition that the software installed might be malicious. This raises questions about the security inherent to Installer packages and whether there might be exploits available using Intel binaries in Rosetta 2, given that it resigns translated executable code.
XCSSET
This was presented in a bogus app named Xcode. Attempting to run that resulted in its detection, and the invitation to remove it, in this case without it being positively identified.
As this was presented as an app containing unsigned code, that came under suspicion early during its assessment, and it was translocated even though it had been moved from its original location SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/s0/[…]/Xcode.app
That appears to have occurred beyond previous rules for translocation.
Gatekeeper and XProtect scans followed, and it was confirmed that the code was unsigned Error Domain=NSOSStatusErrorDomain Code=-67062
Unsigned code in: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 81906), (team: (null)), (id: (null)), (bundle_id: (null))
CDHash checks using CloudKit didn’t find a match, and were simply reported as ticket not available: <private>
Gatekeeper’s scan reported that the app didn’t contain a bundle, but XProtect found no match with current Yara rules. The decision was made to present the malware warning prompt present prompt: uid=501, conn=yes, type=Malware, op.ident=A66F9ED6-EDE7-48E9-B1F8-74CB77C43C9E, info.ident=39D1FBB5-2620-483B-AD3C-6FC5118A406F, info={<private>}
and the attempt to launch the app was blocked.
As these traits would still be detected with SIP and Gatekeeper disabled, all four VMs blocked the code and displayed the same alert to the user.
Limitations
In reality, it’s common for attacks to consist of the initial download of a small dropper, which in turn downloads the main payload. One of the disadvantages of testing malware samples is that this presentation of the payload can’t be taken into account. Payloads are often downloaded using methods that escape quarantine. Another significant difference is that samples often lack code signatures that may be present in the originals, and may change frequently as Developer certificates are revoked and replaced.
Detection information
There appears to be almost no information on how macOS detects different groups of malicious software. Inevitably, Apple provides none at all, and few in-depth analyses of malware give any details about its presentation, in terms of any signatures used, and whether they or CDHashes have since been revoked by Apple. This is a difficult area, given that many of those who analyse and report on malware work for vendors of security products. There appears to be a valuable role for independent assessment of whether and how detection takes place in macOS, major factors in any risk assessment.
I’d like to express my gratitude to the Objective-See Foundation for collecting and making available its extensive library of malware samples, without which none of these tests would have been possible.
Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5272. Apple has now released this for Sequoia betas as well, using their new update mechanism.
Apple doesn’t release information about what security issues this update might add or change. This makes a small amendment in the Yara definitions to the detection signature for MACOS.d98ded3, and adds another rule to those to detect MACOS.DOLITTLE, in MACOS.DOLITTLE.DOFSTRGT.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5272.
If you’re running a Sequoia beta and are still stuck at 5271, don’t worry if sudo xprotect check
doesn’t offer you the update to 5272. Ignore it and run sudo xprotect update
and with any luck it will update your Mac to 5272.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
In the first of these articles, I examined security aspects of the process of launching various app configurations in macOS Sonoma 14.6.1, on an Apple silicon Mac with full boot security and other security settings. This article moves on to discover how those change when boot security and security settings are reduced. Full details of how this was done are given in the previous article.
To remind you, the apps used were:
SystHist – notarized, quarantined, moved from its landing folder to avoid app translocation;
SilentKnight – notarized, not quarantined, previously run;
Sparsity – notarized, not quarantined, not previously run;
DelightEd3 – not notarized, signed with a Developer certificate, not quarantined, not previously run;
DelightEd3resigned – not notarized, ad hoc signed, not quarantined, not previously run.
None of the apps run in an app sandbox, and those notarized use a hardened runtime.
This article covers these three variants of the same 14.6.1 VM:
Full Security, with Gatekeeper/XProtect disabled;
Permissive Security, with SIP disabled;
Permissive Security, with both SIP and Gatekeeper/XProtect disabled.
In each VM, settings were confirmed using SilentKnight, which in turn calls standard system tools to determine current security settings, such as those when both SIP and Gatekeeper were disabled.
Gatekeeper disabled
Surprisingly, with Gatekeeper assessments disabled, com.apple.syspolicy.exec still reported that Gatekeeper assessments were made GK process assessment: <private> <-- (<private>, <private>)
Gatekeeper assessment rooted at: <private>
and later queueing up scan for code: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 69229), (team: (null)), (id: (null)), (bundle_id: (null))
GK performScan: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 69229), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
Following that, XProtect scanned XPAssessment performAnalysisOnFileImpl continueOnError set to 0
Xprotect is performing a direct malware and dylib scan: <private>
using its standard Yara rules.
CloudKit ticket lookup also proceeded as normal. After a while, though, XProtect announced Xprotect is skipping executable assessment: <private>
The normal prompt for user consent was displayed, and handled as expected. Following that, launch proceeded normally.
Similar entries appeared in the checks made on all apps that had undergone Gatekeeper and XProtect assessment when full security was in force. There is nothing in the log entries to indicate that disabling Gatekeeper had any effect on the checks that were made, although as none of these apps failed assessment, it’s possible that any failures would have been ignored.
SIP disabled
When SIP was disabled, the structure of pre-launch assessments changed, and appeared disordered in comparison to those performed under full security and with only Gatekeeper disabled. Most notable, perhaps, was the almost complete absence of log entries from the com.apple.syspolicy subsystem, which in full security is so prominent, although its service syspolicyd did appear in entries.
Although quarantine was recognised, no entry reported the start or conclusion of any GK (Gatekeeper) assessment, nor subsequent XProtect scans. Instead, the XProtect service wrote Bundle is not apple signed
Bundle size result: 18388222 (YES)
Always scan: YES
Normal ticket checks were made via CloudKit, but shortly after those were completed, XProtect tried to use its standard Yara rules, and ran out of memory doing so, with the kernel reporting process XprotectService [697] crossed memory high watermark (15 MB); EXC_RESOURCE
XProtectService therefore ran into trouble before it had even started to scan the app. While some entries suggested prompting the user for their consent, that doesn’t appear to have happened. Eventually the app launched in spite of the disorder that had preceded.
When launching a notarized app that wasn’t quarantined, neither Gatekeeper nor XProtect appear to have had any involvement in the approval of the launch.
SIP and Gatekeeper disabled
Results were essentially identical to those obtained with SIP alone disabled, even down to XProtectService exceeding its memory high watermark, and the almost complete absence of log entries from the com.apple.syspolicy subsystem.
SIP and Gatekeeper settings
Prior to examining these log records, I thought I had a clear idea as to what these two controls do. In fact, neither of them does what you’d expect.
Disabling Gatekeeper or XProtect checks doesn’t stop them from occurring, although it might result in macOS ignoring any errors they might find. That would be consistent with the statement in the spctl man page: “Operations that would be denied by system policy will be allowed to proceed; assessment APIs always report success.”
On the other hand, disabling SIP almost completely stops the whole com.apple.syspolicy subsystem, which ordinarily plays a major role in pre-launch checking of apps. This effectively kills both Gatekeeper and XProtect, leaving those checks in disarray. When the XProtectService tries to lend a hand, its attempt to ingest the current Yara rules runs it out of memory, and it appears unable to render any useful assistance to the pre-launch checks.
This may explain why disabling SIP has the effect of shortening the time to launch an app, most noticeably with larger and more complex apps. In return for launching in a shorter time, the app probably isn’t checked against XProtect’s Yara definitions, so could still contain malicious code that would pass undetected.
In the next article I’ll show what does happen when this system encounters live malware.
This is the first of a series of three articles that look in detail at the launch process of apps in macOS Sonoma 14.6.1, with the emphasis on security checks. This follows my earlier look in 14.4.1, and covers a wider range of situations, including the effects of disabling SIP and Gatekeeper, and how known malicious software is handled.
Methods
All tests were performed in a series of Sonoma 14.6.1 virtual machines (VMs) running on a Mac Studio M1 Max host, also running 14.6.1. VMs are preferred as they enable a consistent environment and easy control of boot security and security settings, together with relatively low rates of log entries. Log extracts were obtained using Ulbow and analysed in their entirety for the first 5-7 seconds after launching apps in the Finder.
Apps used were:
SystHist – notarized, quarantined, moved from its landing folder to avoid app translocation;
SilentKnight – notarized, not quarantined, previously run;
Sparsity – notarized, not quarantined, not previously run;
DelightEd3 – not notarized, signed with a Developer certificate, not quarantined, not previously run;
DelightEd3resigned – not notarized, ad hoc signed, not quarantined, not previously run.
None of the apps run in an app sandbox, and those notarized use a hardened runtime.
Four variants of the same 14.6.1 VM were run:
Full Security, with SIP and Gatekeeper/XProtect enabled;
Full Security, with Gatekeeper/XProtect disabled;
Permissive Security, with SIP disabled;
Permissive Security, with both SIP and Gatekeeper/XProtect disabled.
All had bridged network access to the network and internet, and shared folders with the host, when running these non-malicious apps.
This article describes what happens in the log in the first of those conditions, full security with both SIP and Gatekeeper/XProtect enabled.
Quarantined notarized app
This underwent the fullest checks of these tests. Once LaunchServices announces that it’s opening the app, the following sequence of events is recorded.
CDHashes from the app are copied, here only those for the Arm architecture. As the app is unknown, it’s next registered with LaunchServices. Gatekeeper assessment is then started just 0.07 seconds after announcement of the launch, in the log entry GK process assessment: <private> <-- (<private>, <private>)
com.apple.syspolicy.exec then starts work on scanning for code, followed by the first mention by LaunchServices that the app is quarantined.
The Gatekeeper scan is announced in GK performScan: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
followed by the XProtect scan in Xprotect is performing a direct malware and dylib scan: <private>
and assignment of the risk category according to its quarantine QUARANTINE: Setting risk category to LSRiskCategoryUnsafeExecutable
XProtect states the Yara rules it’s using Using XProtect rules location: /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara
com.apple.syspolicy next processes the app’s notarization ticket looking up ticket: <private>, 2, 1
by trying to fetch its record using CloudKit. That’s followed by entries indicating the network access required to connect with iCloud and check the ticket. Success is reported by com.apple.syspolicy in CKTicketStore network reachability: 1, Mon Aug 26 09:15:45 2024
looking up ticket: <private>, 2, 0
and further lookups.
A little later, Gatekeeper announces the XProtect results GK Xprotect results: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), XPScan: 0,-7676743164328624005,2024-08-26 08:19:01 +0000,(null)
and its scan is complete GK scan complete: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), 4, 4, 0
Because this is the first launch of a quarantined app, com.apple.syspolicy.exec decides it gets a first launch or “code-evaluation” prompt “because responsibility”. If the user gives approval, the app is allowed to proceed. Its quarantine flag is updated, and the bundle record registered as trusted. The final step is then to create and save its provenance data Created provenance data for target: TA(e8217440d9326f59, 2), PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)
Handling provenance root: TA(e8217440d9326f59, 2)
Wrote provenance data on target: TA(e8217440d9326f59, 2), PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)
Putting executable into provenance with metadata: TA(e8217440d9326f59, 2)
Putting process into provenance tracking with metadata: 692, TA(e8217440d9326f59, 2)
Tracking process with attributes: 692, TA(e8217440d9326f59, 2)
Without quarantine
A notarized app that hasn’t been run previously on that system and isn’t quarantined undergoes a similar sequence, but without the first launch or “code-evaluation” prompt. Its bundle record is registered as trusted, rather than being classified as an Unsafe Executable, but it still gets a full XProtect scan and ticket lookup using CloudKit.
Subsequent launches
The briefest launch process is that for an app that has only recently been run. That appears to skip Gatekeeper and XProtect assessments, and there’s no ticket lookup either. Pre-launch processes can then take less than 0.1 second.
Launching a known app following a cold boot can be as quick, although in this case there is a brief Gatekeeper assessment reported in the log. The key entry here comes from com.apple.syspolicy.exec: Code already evaluated, using results.
Those are checked by Gatekeeper before launch proceeds, with the kernel reporting evaluation result: 2, exec, allowed, cache, 1724654056, 4, c0a2e35c20a69dfd, /Applications/SilentKnight.app
Signed with developer certificate
An unquarantined app that isn’t notarized but is correctly signed using a Developer certificate is similar to its notarized equivalent, except that looking up the ticket using CloudKit is of course unsuccessful. Repeated attempts are made to find it, though, before going on to check “the legacy list” and check “legacy policy”. This results in the decision Match downgraded from DevID to None based on legacy policy for: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 60118), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
but the kernel decides to allow launch to proceed evaluation result: 6, exec, allowed, cache, 1724660700, 0, 9576bac3e248c07b, /Applications/DelightEd3.app
Ad hoc signature
This is detected early during pre-launch checks by AMFI (Apple Mobile File Integrity), despite the bundle record being registered as trusted. The kernel reports AMFI: '/Applications/DelightEd3resigned.app/Contents/MacOS/DelightEd' is adhoc signed.
AMFI then records No certificate chain found
Failure getting cert chain
Basic requirement validation failed, error: Error Domain=NSOSStatusErrorDomain Code=-67050 UserInfo={SecCSArchitecture=<private>}
and an error code of -423, given as “The file is adhoc signed or signed by an unknown certificate chain”.
Despite that, Gatekeeper assessment continues, with an XProtect scan. Attempts to look up the app’s ticket inevitably fail despite many attempts, and an error code of -67018 “Code did not match any currently allowed policy” is awarded. Launch then proceeds.
In the next article I’ll show how those are affected by disabling SIP and Gatekeeper assessments.
Reviewing security products intended to detect and remove malicious software is far harder than it used to be. There was a time when all you had to do was set your virtual machine to Reduced Security, disable SIP, and maybe Gatekeeper too, then strip any quarantine extended attributes from samples of recent malware. With nothing to trigger checks by macOS security, the malware was fully exposed to the security software under test, and you could assess how successful the product was at detection.
Yet in Sonoma it seems that you also need to disable AMFI (Apple Mobile File Integrity), or macOS will intervene to detect the malware before the product under test, which then won’t get a look-in.
Back in Sonoma 14.4.1 I summarised those layers of checks in this diagram.
Although it’s encouraging that malware detection is now so pervasive, this makes it almost impossible to assess the other side of an anti-malware product, how well it can remove the malicious software it discovers. The same applies to Apple’s own XProtect Remediator. Stunting and tricking macOS to the point where malware can deploy fully isn’t anywhere near as easy as it was.
You know you have failed again when macOS pops up an alert like this, telling you that it has intercepted your attempt to bypass its protection.
From a user’s point of view, this can only be good. macOS security protection is designed and applied in multiple layers so that, even if something manages to trick its way past one check, the next layer is there to stop it in its tracks.
The strangest thing about XProtect Remediator isn’t the fact that, left to its own devices, it doesn’t inform the user when it detects malware, but that it will happily remove the malware it detects and let you carry on using your Mac as if nothing had happened. If you’re as old school as me, you might wonder why you shouldn’t have to wipe your Mac completely, restore it in DFU mode if an Apple silicon model, and rebuild it from scratch. Surely the slightest suspicion of anything malicious demands such a scorched earth approach?
That too depends on what security protection your Mac has active. If that includes SIP and the SSV, then there’s no known malware that can alter anything on the SSV, and what it can do on your Data and other volumes is also limited. The days of viruses wreaking havoc throughout your entire Mac thankfully seem long since past. Viruses, of course, were designed to replicate themselves throughout a Mac’s storage, but today’s trojans and stealers are after two things, and those are your secrets and money.
But that depends on the behaviour of potential victims of malware. Like any business, those who try to profit from theft of our secrets and other malicious behaviour have to consider the size of their market of victims. For many years, this was one of the Mac’s defences against malware: why would anyone want to develop for such a small proportion of potential victims, when PCs readily provided far more? More recently, some have unfortunately recognised our potential, and now we’re suffering the consequences.
This is where standard macOS security protection comes into play. At present, the great majority of Macs running Big Sur or later have SIP enabled and their SSV fully protected. The victim market for malware requiring write access to the System volume is tiny. But what if it became more usual for Macs to be unprotected, and all that malware had to do was gain root privileges to be able to write to the System volume?
This is a phenomenon akin to vaccination and resulting herd immunity in pandemics like Covid. States and nations with low protection by vaccination and little herd immunity suffered the highest rates of infection and consequent death rates. But so few realised that exercising their personal choice to remain unvaccinated had that effect, despite the fact that humans throughout the world had eliminated the deadly disease of smallpox by building herd immunity in the late twentieth century.
Security protection in macOS works in layers. Each layer you disable opens wider the window of opportunity for attackers. The more Macs that have any given layer of protection disabled, the lower the herd immunity to attack, and the more likely that malware will try to take advantage of that.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 142. It appears this version was first released over 12 hours ago, early in the morning GMT, but was then removed from Apple’s update servers. It has just now been made available again.
Apple doesn’t release information about what security issues this update might add or change. For the first time since its release, this update removes a scanning module, for RedPine. Bastion rules remain unchanged.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-142.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
It’s not uncommon for mid-cycle releases of macOS to gain new features in preparation for the next major version. Perhaps the most fundamental and significant added to Sonoma 14.4, together with iOS 17.4, iPadOS 17.4 and watchOS 10.4, are exclaves. As far as I’m aware, this is the first time this term has been used in computing, so before trying to explain what they do for our Macs, I’ll demystify its established use in geography.
Definitions
An enclave is a country that’s entirely surrounded by another country, and it’s easy to see how that matches its meaning in the Secure Enclave, which handles our most important secrets, and provides FileVault encryption. Those are highly secure services provided by a separate processing unit within the main Apple silicon chip, or the T2 in recent Intel Macs.
An exclave is a fragment or part of a country that’s separated from the main part, and lies within one or more countries other than its original country. Although I haven’t come across an explanation of what this represents in computing, for these purposes I assume that an exclave is a resource that’s separated from its parent, for example a small portion of Secure Enclave that’s outside the main part, supporting a virtual machine, perhaps.
Although I hadn’t previously come across the term conclave in computing, Apple is now using it in recent versions of the XNU kernel. This isn’t derived from geography, but is normally used for a private meeting or close assembly, most specifically the meeting of cardinals that elects the next Pope. While there’s scant evidence as to its meaning in this context, I’ll assume that it’s based on that general concept.
Secure Enclaves
Apple introduced its first true Secure Enclave for Macs in the T2 chip in December 2017. This chip consists of a four-core main CPU derived from the A10 used in the iPhone 7 and contemporaneous iPads and iPod Touch, with a 32-bit Arm CPU running a completely different operating system, sepOS (a custom version of the L4 microkernel), dedicated to handling and working with the secrets protected by its Secure Enclave. That has its own secure EEPROM storage, an AES engine to perform hardware-accelerated encryption and decryption for the internal SSD, and more.
The first M1 models released in November 2020 came with an integral Secure Enclave, as have all subsequent M-series chips. These are a significant improvement on their predecessors in the T2, adding replay prevention, a second-generation Secure Storage Component, and more. They continue to run their own operating system, sepOS. Support for biometric authentication using Face ID is implemented as a secure mode in the main Neural Engine (ANE), but apparently remains unused in M-series chips. That secure ANE mode is an exclave of the Secure Enclave.
Exclaves
Prior to macOS Sequoia, macOS virtual machines (VMs) running in lightweight virtualisation on Apple silicon are unable to use Apple ID or to access iCloud, because they’re unable to access any protected secrets from the host’s Secure Enclave. In macOS 15 and later, creation of a VM running macOS 15 or later can configure an identity derived from the host Secure Enclave, enabling access to resources requiring Apple ID including iCloud. This is accomplished using an exclave of the Secure Enclave.
As of macOS 14.6.1, exclaves and conclaves are implemented in and supported by three kernel extensions:
ExclaveKextClient.kext (introduced in macOS 14.0)
ExclaveSEPManagerProxy.kext
ExclavesAudioKext.kext
and two Private Frameworks:
CoreSpeechExclave.framework
libmalloc_exclaves_introspector.framework
These are currently all in version 1.0. If you’re running a beta-release of Sequoia, you might find it interesting to check the version numbers of those components in their respective /System/Library folders.
According to the few comments in the XNU source code, exclaves provide a fixed static set of resources to the XNU kernel. Examples given include conclave managers, services like Apple ID for VMs, named buffers and audio buffers. These resources are named and have a corresponding identifier shared between XNU and the enclave. Those are discovered during the boot process, and made available in a table at two levels. The root table assembles resources by their scope, while secondary tables list actual processes.
For example, a root table entry for the domain com.apple.conclave.a might link to a secondary table listing an audio buffer, an audio service as a conclave manager, and additional buffering. In the case of audio exclaves, they might be used to connect a system extension running with user privileges to privileged access in the kernel and its extensions.
Information about exclaves is hard to come by. Currently, it appears that any log entries originating from exclaves are shown as coming from the kernel. The only time you’re likely to come across more specific information is in the panic log generated following a kernel panic involving an exclave, when the normal content should be supplemented by information from the exclave. These might have improved in Sequoia.
From the evidence in XNU source code and elsewhere, exclaves are intended to support three subsystems:
audio system extensions, allowing them to replace third-party kernel extensions, via ExclavesAudioKext.kext
Apple ID in macOS VMs via ExclaveSEPManagerProxy.kext
secure ANE via ExclavesAudioKext.kext.
Although support for each of these first appeared in macOS 14.4, the second of them, at least, is already functional in Sequoia, but hasn’t been back-ported to Sonoma, restricting its use to Mac hosts and VMs running Sequoia or later.
There are also multiple references to Tightbeam, which doesn’t appear to have been released in open source. This refers to highly focussed lasers used in communications in The Expanse sci-fi. In macOS, it first appeared as the name of a Private Framework released in macOS 13.0, and supported since then. There’s still a great deal more to be discovered about exclaves, conclaves and XNU.
Despite the worst efforts of Elon Musk to destroy everything good that remains of Twitter, it came to my rescue yet again when I recalled a tweet from @L0Psec from 12 June. That had announced a new command tool he discovered in early macOS Sequoia betas that also solved the mystery of what had gone wrong last week in my MacBook Pro’s security data updates.
I hadn’t had time to investigate the new command back in June, but when I noticed that my beta-test system had failed to update to XProtect version 5271 and wouldn’t even offer that update, it occurred to me a tool named xprotect might cast light on this mystery. Sure enough, when it assured me that the update had been installed after all, I could piece together what had happened and search Apple’s release notes unsuccessfully for an explanation. At some time between 23 July when version 5270 was released, and 6 August when it was replaced by 5271, Sequoia’s mechanism for updating XProtect’s data had changed completely without so much as a brief warning.
In that period of a fortnight, XProtect stopped behaving as it had for the last 15 years, since it was introduced in Mac OS X 10.6 Snow Leopard in August 2009. The version number of XProtect.bundle in CoreServices became a relic of the past, and didn’t show that actually installed. Software Update and softwareupdate, which had happily delivered hundreds of previous updates, had now fallen silent about XProtect.
Macs running older versions of macOS still found and installed the latest version, but not those running Sequoia. When it did appear, among the many listed by System Information in Installations, it was named as XProtectCloudKitUpdate, implying it had been downloaded from iCloud using CloudKit. I have later confirmed that obtaining this update doesn’t require the user to be signed in to iCloud, and it has joined the army of maintenance services using iCloud servers.
Updating XProtect in Sequoia
If you’re not using the latest version of SilentKnight, which now does this automatically, you can check the version of XProtect data installed on your Mac using the command xprotect version
If that or SilentKnight reports an older version than expected, and you want to manually check and install any available update, rather than using softwareupdate, use sudo xprotect check
Then, if there is an update available, obtain and install it with sudo xprotect update
both of which will require you to authenticate, as they must be run with elevated privileges.
I am working on a new version of SilentKnight that will save you the trouble of using Terminal to do that. Details of this new command tool xprotect are available in its man page, or from xprotect -h
although neither explains how this has changed, or why.
Why change?
The early years of XProtect saw emphasis on blocking vulnerable and exploited versions of Adobe Flash Player, and its Yara detection rules developed only slowly. When Adobe finally killed Flash Player at the end of 2020, attention turned to XProtect’s role of detecting and blocking other malicious software when it was first launched.
Its Yara rules grew steadily, as did the size of its XProtect bundle. Version 2109 from 27 September 2019 was 228 KB, and had risen to 2.5 MB by the update to 2178 of 4 January this year. This growth has accelerated lately, and version 5271 released on 2 August reached a total of 3.2 MB. The number of Yara rules contained in that bundle has exploded since the start of this year, with version 2192 on 23 April adding no less than 74 new rules tackling Adload malware, all in a single update.
Releasing new versions through Software Update is a slow and complex process, geared better to low frequencies. Before 2020, XProtect had usually been updated every month, but this year alone there have been 20 updates in less than eight months. Updating XProtects’s Yara rules using iCloud should be quicker, more efficient, and capable of promulgating changes more frequently. Apple could issue new rules as they’re developed and tested, then provide summary updates for Sonoma and older macOS to catch up every 2-4 weeks.
Presumably, these new iCloud updates transfer their payload as binary data rather than verbose Yara text definitions. If they do use CloudKit, then they could directly update a Mac’s security database, much as apps using CloudKit already do, and as used to update notarization data.
Older macOS
Alongside its sibling XProtect Remediator (XPR), XProtect is the front line of Apple’s campaign against malware. XPR was introduced in macOS Monterey two years ago and backported to Catalina and Big Sur. As it’s more of a standalone service, that doesn’t appear to have required much change in those older versions.
This new delivery mechanism for Sequoia is more likely to require internal surgery to security sub-systems, and appears less likely to be offered in Sonoma or Monterey. There are still many Macs running older versions of macOS no longer receiving macOS security updates, and I expect Apple will want to continue offering them more traditional updates for the foreseeable future. Those will also enable security researchers to keep a watch on which malware XProtect can detect using the rules in its Yara file.
Informing beta-testers
I’d like to thank @L0Psec for being the only person to draw attention to what would otherwise have appeared a worrying situation, and to remind Apple of the need to keep beta-testers informed. We’re all keen to keep our test systems well-protected, and should have been warned of this change, and told of the new command tool, rather than hearing about it in the scarred remains of what used to be Twitter. I hope this will be rectified for the next public beta-release, or there could be an avalanche of Feedback reports.
It’s no good telling us that XProtect “uses YARA signatures, a tool used to conduct signature-based detection of malware, which Apple updates regularly”, then those updates are obfuscated.
Imagine my surprise earlier this week when I went to ensure my MacBook Pro had successfully installed new versions of XProtect and XProtect Remediator. SilentKnight informed me that XProtect was still at version 5270, and there was no update available to take it to 5271. I then manually checked the version of XProtect.bundle in CoreServices, and that confirmed it hadn’t been updated, but SilentKnight still couldn’t find any update, despite XProtect Remediator updating as normal.
My next visit was to the list of Installations in System Information, where it informed me that XProtect had been updated to 5271, thanks to XProtectCloudKitUpdate, instead of the usual XProtectPlistConfigData installation downloaded through softwareupdate. After a little jiggling with the new xprotect command tool I realised what had happened, and why SilentKnight was awry.
After an unfortunate delay, described later, I’m at last able to offer a new version of SilentKnight that won’t make this same mistake when run in recent beta-releases of Sequoia. Version 2.10 now detects whether it’s running on Sequoia; if it is, instead of inspecting the version of the XProtect.bundle in CoreServices, it now uses the official method of xprotect version
instead.
Sadly, things get more difficult if XProtect is out of date. SilentKnight can’t use its normal call for update installation to softwareupdate, as that doesn’t handle XProtect updates any more in Sequoia. The official method is first to check whether an update is available using xprotect check
then perform the update with xprotect update
Although that might seem simple enough for SilentKnight to handle, both of those calls need to be made with elevated privileges. In Terminal, you’d just preface them with sudo, but apps can’t do that, and should normally use a privileged helper app, running with root privileges, something none of my apps do yet.
There’s another problem for SilentKnight in that it now needs to use two separate methods of checking for updates, and that in turn requires its code to be completely rewritten, a task I’m deferring to a whole new version, SilentKnight 3, which will only run on Sequoia. Until that’s available, bear with me and use the xprotect commands above as you need (remembering to sudo them); at least SilentKnight will now indicate when that might be necessary.
SilentKnight version 2.10 is available from here: silentknight210
from Downloads above, from its Product Page, and through its auto-update mechanism. Apart from fixing any remaining bugs, I intend this to be the final release of SilentKnight 2 with support up to and including macOS Sonoma, when updating remained so simple.
You can see the effect during one of my tests in a freshly made Sequoia VM.
At first, there’s apparently no XProtect installed at all, and the command tool returns a version of 0. Although there are updates offered for MRT (really?), Gatekeeper Compatibility Data and XProtectPayloads (XProtect Remediator), none is offered for XProtect.
I then manually updated XProtect using the command tool, and ran SilentKnight 2.10 again.
Immediately afterwards, XProtect is at the current version number of 5271 even though there’s no XProtect.bundle in CoreServices, and there’s no record of that update in the list of latest updates. That’s listed in the new version of SystHist, though, giving its mysterious XProtectCloudKitUpdate origin.
This update has been released a day later than I intended, because of a disorientating bug that caused the app to crash early whenever it tried to start up, complaining of an unreachable file path when it was starting to run its main code. I suspected a problem in the structure of the app and chased many red herrings before I realised this was the result of overenthusiastic code.
I have put the call to the xprotect command tool into conditional code, with an if to check whether it was running on Sequoia or earlier macOS. Apparently the path to the command was being checked before the instructions discovered whether that code would be run. As the path to the command tool doesn’t exist on earlier macOS, when it was being checked before determining which macOS was running, that was failing in Sonoma, as expected. Once I had worked out where this was occurring, without any clue from the errors, I had to change the type of conditional test used so the code didn’t check a non-existent path on older macOS.
Soon after the first beta-release of macOS 15.0 Sequoia, I noticed a post on X (formerly Twitter) reporting a new command tool xprotect, but never got the chance to take a look at it. With recent updates to the beta versions, its purpose has become clear: Sequoia uses a different mechanism to update its XProtect data. And that’s not compatible with any of my security update utilities, LockRattler, SilentKnight, Skint, or even SystHist.
The reason for this is that, in all previous versions of macOS going back many years, XProtect data are stored in a bundle named XProtect.bundle, where you (and my apps) can check its installed version number. But in Sequoia that bundle is neither used nor updated when XProtect data are updated. Indeed, Software Update and its command tool equivalent softwareupdate, used by my apps, can’t even see XProtect updates any more, as they’re checked and installed using a different mechanism, which is where the xprotect command tool comes into play.
Run any of those apps on a recent version of Sequoia, and they’ll dutifully report the version of XProtect found in that bundle, which will now be out of date, but the update is apparently not available, although in many cases it has already been installed and protection is up to date!
Unfortunately, as is so often the case, searching Sequoia’s release notes and other Apple sources fails to discover any information about this change, or the xprotect command tool.
SystHist was due its annual update anyway, so its new version 1.20 now handles Sequoia updates and (as well as it can) reports those it can find to XProtect. This new version is available from here: systhist120
from Downloads above, from its Product Page, and through its auto-update mechanism.
Skint (and its menu bar companion SkintM) version 1.08 now checks correctly for the XProtect version in Sequoia, and is available from here: skint108
from Downloads above, from its Product Page, and through its auto-update mechanism.
I’m not proposing updating LockRattler to address this issue, as SilentKnight and Skint are now capable of handling most needs. If this distresses you, please let me know and I’ll see what I can do in the coming weeks. However, without major internal surgery it’s never going to work fully with Sequoia, I’m afraid.
I was hoping to release a new version of SilentKnight today too, but Xcode gremlins are currently blowing that away, and I fear I have some reconstruction needed before it will do anything other than crash! As soon as I have a stable release, I will make it available.
These changes are sufficient to make it unwise to continue with the current major version of SilentKnight, as all its update code needs to be reworked so that it handles other updates through softwareupdate, as it does at present, and has a privileged helper app to obtain updates using the new mechanism for XProtect alone. My intention therefore is to provide one final update to SilentKnight 2 that will work without being able to update XProtect in macOS 15. That will be the final release to support macOS Catalina to Sonoma. The new version will be SilentKnight 3, will require Sequoia, and I hope will be released before Sequoia 15.0 hits the streets.
I apologise for this, and for the mess it’s causing for SilentKnight in Sequoia, but as you’ll appreciate this is all way beyond my control. I will also be writing further about what appears to be happening with XProtect for the weekend.
Apple has just released patch updates to bring macOS Sonoma to version 14.6.1, and Ventura to 13.6.9. There’s no update for Monterey, though.
There are no entries for these updates in Apple’s security release notes, which simply report “no CVE entries” for both. However, the matching updates for iOS apparently refer to important bug fixes, including one that prevented changing Advanced Data Protection settings. Whether that’s the same for Sonoma and Ventura is anyone’s guess.
There are no updates to firmware on T2 Intel models, or on Apple silicon, and Safari’s version and build numbers haven’t changed either.
The 14.6.1 update is just over 650 MB to download on Intel systems, and around 1.4 GB on Apple silicon.
Looking through the contents of the /System folder shows small build increments in the Security framework and some keychain-related files such as Keychain Circle Notification app. There are no other changes in /System or the bundled apps at all.
Apple has just released updates to XProtect Remediator security software (Catalina or later), bringing it to version 141, and to XProtect (for all macOS from El Capitan or so) bringing it to version 5271.
Apple doesn’t release information about what security issues these updates might add or change.
XProtect’s Yara definitions add two further signatures to its long list of those for MACOS.DOLITTLE, these being qualified as DOFNPXR and DOFDLMARM.
XProtect Remediator adds a new scanning module for Dolittle, the same codename that has just had a family of 14 detection rules added in XProtect. There are no changes to Bastion rules for the behavioural version of XProtect (Ventura and Sonoma only).
You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-141 and XProtectPlistConfigData_10_15-5271.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
It’s common knowledge that Apple supports each version of macOS for a full year of updates, then a further two years of security updates. But for how long does it support the firmware in each model? Now that the only way to update a Mac’s firmware is by installing a macOS update, how does that affect the support period? This article tries to answer those questions, and in doing so unearths a bit of a mystery that happened just over a decade ago.
Data
Apple doesn’t release any information about firmware versions or updates, and they very seldom even get a mention in its release notes for security updates. Fortunately, as I have been tracking firmware versions for each model since the release of High Sierra seven years ago, I have my own records derived from the versions contained in macOS updates. I’ve matched those against the model introduction and discontinuation dates given in Ian Page’s Mactracker database, and here summarise the results.
How updates work
Each macOS update may bring firmware updates, although pure security patches during the first year of support tend to bring fewer. Firmware updates are the same across all three macOS updates normally released at the same time. So those brought in the recent update to 14.6 are the same as those in 13.6.8 and 12.7.5, for models supported by each, but each update only installs updates for those models it supports. This becomes clearer with the aid of examples that also reveal the inner mystery of these updates.
On 15 July 2020, the main update brought macOS 10.15.6, and alongside it security updates (SU) for macOS 10.13 and 10.14. Those included the following EFI firmware versions:
for iMac12,1 version 87.0.0.0.0 of 14 June 2019
for iMac13,1 version 292.0.0.0.0 of 10 June 2020
for MacBookPro8,1 version 87.0.0.0.0 of 13 June 2019
for MacBookPro9,1 version 233.0.0.0.0 of 10 June 2020.
The two firmware versions dated 2019, for iMac12,1 and MacBookPro8,1, were a year old at that time, as Apple had discontinued releasing new firmware versions for those two models in June 2019. However, iMac13,1 and MacBookPro9,1 models received a new version of their firmware if they had macOS 10.15.6 or either of the security updates installed.
A year later, on 21 July 2021, Apple released the update to macOS 11.5, and with it Mojave SU 2021-005. As the iMac12,1 and MacBookPro8,1 were no longer able to run a supported version of macOS, neither had a firmware update, leaving them running the versions from June 2019. The two more recent models then had the following updates:
for iMac13,1 version 422.0.0.0.0 of 4 June 2021
for MacBookPro9,1 version 422.0.0.0.0 of 4 June 2021.
Another year later, on 20 July 2022, both those models could still run supported macOS, and had the following firmware updates in Catalina SU 2022-005:
for iMac13,1 version 429.0.0.0.0 of 18 Mar 2022
for MacBookPro9,1 version 429.0.0.0.0 of 18 Mar 2022.
But those weren’t new in that SU, as by that time firmware updates for those two models had been discontinued, and in Big Sur 11.7.7 on 18 May 2023, neither model had any firmware available as they were no longer supported by a version of macOS that still received updates.
The stark fact revealed in this example is that, for consecutive models of iMac and MacBook Pro, released just over a year apart, there had been almost three years difference in the last firmware update released:
for iMac12,1 last release June 2019, for iMac13,1 last release March 2022
for MacBookPro8,1 last release June 2019, for MacBookPro9,1 last release March 2022.
How long?
I therefore compiled data for 40 different model designations of Intel Macs without T2 chips introduced from October 2009 to the present, each of which had apparently passed its final firmware update. That excludes the few models that are still receiving firmware updates now.
This chart shows the dates of each model’s last firmware update by the date of introduction of that model. There’s a large cluster of Macs introduced before 2012 that received their final firmware update in June 2019, then a gap of almost two years during which all later models received further firmware updates, before the next batch of older models, this time from 2012-13, received their final updates. There’s an outlier visible at the top right, the iMac19,1, introduced in March 2019, but which appears to have undergone its final update in February 2024, exceptionally early. Although that has received no firmware updates since, it’s plausible that it may yet receive more in the future.
This chart shows the total length of firmware support in years by the date of introduction of that model. There are three distinct groups:
models from before 2012, forming a steep line at the left, with support times ranging from just under 8 to nearly 10 years;
more recent models, forming a less dense scatter with support times from just under 7.5 to almost 10 years;
the iMac19,1 outlier at the bottom right, with its exceptionally short support time of about 5 years.
This is the same chart with superimposed labels giving each model’s designation. There doesn’t appear to be any association between model range (e.g. iMac) and length of support.
Thus, for most Intel models without T2 chips introduced since 2009, support for firmware updates has extended to at least 8 years since their introduction. As the period between introduction and discontinuation of models varies widely, there is greater scatter when these are expressed in terms of the date of discontinuation.
The gap
There are several possible reasons that might account for the gap between Macs introduced before 2012 and those introduced more recently. These include:
the transition from Sandy Bridge to Ivy Bridge in Macs introduced in 2011-12;
an intended period of stability in Intel Macs during the introduction of Apple silicon models;
a choice by Apple not to discontinue firmware support during the Covid pandemic, although I don’t recall that ever being articulated;
an arbitrary change in Apple’s firmware support policy.
Of those I favour the transition away from Sandy Bridge, which is known to have had problems that may have resulted in firmware support being curtailed earlier than would have been intended.
It’s important to note that this gap doesn’t mean that firmware updates weren’t released during that period, merely that models still being updated during that time continued to do so, with none being terminated then.
T2 and Apple silicon
These more recent models, introduced from 2017 on, change firmware updates completely. All Macs with T2 chips receive what appear to be identical firmware updates. Instead of further updates being abandoned despite a Mac still being supported by macOS updates, as happened in some cases, it appears more likely that T2 firmware updates will only cease when a model is no longer supported by macOS updates.
With Apple’s complete ownership of hardware and operating system in Apple silicon Macs, it’s within its gift to determine how long each will be supported.
Conclusions
For most Intel Macs without a T2 chip, Apple has provided firmware updates for at least 8 years after that model’s introduction. For many models, that occurred before they became unable to run a supported version of macOS.
Some Macs introduced before 2012, with Sandy Bridge chipsets, had firmware support withdrawn early. The reason for that isn’t clear, but may relate to their chipset.
If you’ve ever snooped inside the hidden Library folder in your Home folder, I’m sure you’ve come across two strange folders there, Containers and Group Containers, and maybe even a third, Daemon Containers. This article explains what they are, why they’re there, and how they’re changing.
What?
Look inside any of the folders within those Container folders and you’ll see a single property list, and a folder named Data, inside which is a miniature Home folder, complete with Desktop, Documents, Library and other folders, just like a copy of most of your Home folder.
Here’s one I made earlier using one of my SwiftUI demo apps named ContentTypes. The .com.apple.containermanagerd.metadata.plist file alongside Data sets out the configuration of the Container, and reveals what these Containers are for in its references to the app sandbox. It also refers to the app’s entitlements, including the essential com.apple.security.app-sandbox that determines the app runs in the sandbox.
Look more carefully at those folders inside Data and you’ll see that most of them are in fact aliases to their originals in your (real) Home folder. One that invariably isn’t is in the path [app name]/Data/Library/Preferences, which should contain aliases to at least two property lists, com.apple.security_common.plist and com.apple.security.plist. It may also contain that app’s preference settings in a property list named according to the app’s name. If it does, then you’re not going to find the app’s preferences in the regular Preferences in your Home folder Library.
Given all the aliases involved, what at first looks like a large hierarchy of folders turns out to be small.
These days, macOS gives it a custom folder icon, and locks everyone else out with No Access in its permissions.
The contents of Group Containers are a bit different. They’re named according to the developer ID and the full name of an app group, and contain just a Library folder. Daemon Containers are named by the UUID of the daemon concerned, and have the Data folder as in regular Containers.
Why?
All apps, with very few remaining exceptions, obtained from the App Store, and some others, are run in an app sandbox. The idea behind this is that by isolating the app from everything else, even if it turns out to be flawed or malicious, it can do no damage except to its own files and data. Of course such an app would also be unable to do anything of use: it couldn’t edit documents in your normal Documents folder, connect to the network or internet, and so on. Each sandboxed app therefore has entitlements that determine exactly what it is allowed to do outside its sandbox.
The first time you run a sandboxed app, that’s one with the sandbox entitlement com.apple.security.app-sandbox, macOS automatically creates it a Container, which is effectively the hierarchy of files and folders that the app has exclusive and unrestricted access to. If the app is to have any access beyond its Container, then it must have an appropriate entitlement or obtain permission to do so. An app’s Container migration manifest determines the files the app needs to be moved to its Container when it’s first created, and the developer can add that to the app bundle’s Resources folder in a file named container-migration.plist.
Sandboxed apps are normally given a Container of their own, that’s stored in the Containers folder. Those in Daemon Containers are for sandboxed helper services, while those in Group Containers can be shared across more than one sandboxed app.
Changes
Because a sandboxed app’s Container holds its files and data, it’s a prime target for unfriendly or even blatantly malicious apps that want to steal your private data. macOS Sonoma and Sequoia have therefore introduced protection to block that. In Sonoma, macOS associates an app’s code signature with its Container. If a different app tries to access the contents of that Container, then the user is asked whether to allow that access. This also applies to those for helper services in Daemon Containers.
Mickey Jin has explored this in depth. In Ventura and earlier, Apple had already started protecting containers owned by certain apps prone to exfiltration by malware, such as Notes and Safari. In Sonoma these are covered by a new privacy category described in alerts as access to “data from other apps”. Mickey has identified vulnerabilities in this, one of which has been addressed in 14.6, the other awaits 15.0.
Sequoia extends this protection, based on System Integrity Protection (SIP), to cover Group Containers, which can only be accessed by apps identified as being members of that group, thus have been given shared access.
Housekeeping
Although its Container is created automatically when a sandboxed app is first run, there’s no feature that removes that Container when that app is uninstalled or removed. While that might appear an attractive proposition, it could easily delete files and data that are still required, making manual removal the only safe option. As your Containers folder might have a thousand or more folders in it, and many of them may not be readily associated with specific apps, cleaning them out appears to be an unsolved problem at present.
Summary
Folders in ~/Library/Containers are sandbox containers for apps, and shouldn’t be removed or tampered with unless you’re sure you know what you’re doing.
Those for helper services are in ~/Library/Daemon Containers, and those shared across apps in the same group are in Group Folders.
Preference settings for sandboxed apps are therefore likely to be found in [App Name]/Data/Library/Preferences rather than in ~/Library/Preferences.
Containers and Daemon Containers are protected in Sonoma, and Group Containers in Sequoia.
Although Containers are created automatically by macOS, removing them requires care to avoid data loss.
It’s unfortunate that, given the over 170,000 words in current use in the English language, one has been chosen for two quite different things in macOS. The two different meanings of the term ownership are now being confused, and as a result some are recommending the wrong solutions for dealing with ownership problems. This article disambiguates them.
Contexts
One type of ownership refers to Unix-style permissions, and is the user whose UniqueID is designated as the owner of a file, folder or volume. This applies to all Macs running macOS, as well as all other systems using a similar permissions system.
The other type of ownership is only found in Apple silicon Macs, and refers to the user who has access to the Owner Identity Key (OIK) required to allow users to resign LocalPolicies for bootable systems on that Mac. I explain this in more understandable detail below, but it has nothing whatsoever to do with permissions.
Ownership in permissions
Your Mac has long user names, short user names, Bonjour names, and plenty of others, but its Unix heart just knows each user as a number, their UniqueID, with the primary admin user being given the UniqueID of 501. Every folder and file on your Mac then has an owner and a group in its permissions.
Browse permissions using Finder’s Get Info and you’ll see these expressed as names. So this preference file, from /Library/Preferences, is owned by me, but to the code that operates the permissions system, that isn’t Howard Oakley, or even hoakley, but the user with the UniqueID of 501.
Suppose that after you set your Mac up, you create a second admin user account, and remove the primary 501 account. The UniqueID for that second account could be anything upwards of 502. As an admin user, 502 can still move and remove the great majority of the files and folders that were owned by account 501, if necessary by authenticating with their password. But every single folder and file that was owned by the 501 account has now been orphaned: its owner UniqueID no longer exists.
This is the sort of problem that Migration Assistant is used to coping with, and if you were to migrate files owned by the 502 account to a new Mac where the primary admin user is still 501, they should end up on your new Mac with the correct ownership. But if you move those files over on an external drive, sooner or later you may hit a problem.
To address this, select a volume in the Finder and Get Info on it. At the foot of its Sharing & Permissions section is a checkbox reading Ignore ownership on this volume. Tick that, and macOS should pretend that the permissions there never happened. If a file is owned by 501 or 502, or anything else, then it should give you full access to it regardless of the UniqueID of your user account. It’s the Get Out of Jail card for permissions, and ideal for drives you move between different Macs, which could have users with different UniqueIDs.
Ownership and LocalPolicy
Apple silicon Macs have a secure boot process that’s configured in part by a LocalPolicy file. You can change its security settings in Startup Security Utility, in Recovery mode, and that is then saved to that boot volume’s LocalPolicy. To ensure that only fully authorised users can configure and change LocalPolicy, those Image4 files are signed, and an Owner Identity Certificate (OIC) is attached to them, and that’s where this different type of ownership comes in. This is all handled during initial setup for the internal SSD, whether the Mac is brand new or has just been fully erased and restored in DFU mode. Where it becomes more significant is when setting up another boot volume, such as a bootable external disk.
The OIC is created and signed by Apple’s Basic Attestation Authority (BAA) server in a complex series of exchanges that occur following initialisation of the default state in initial setup. This is summarised in the diagram below.
Creating and maintaining LocalPolicies requires a user to have access to the private OIK in the Secure Enclave, making that user an Owner. Apple states: “Access to the Owner Identity Key (OIK) is referred to as ‘Ownership.’ Ownership is required to allow users to resign the LocalPolicy after making policy or software changes.” Any user with access to the Volume Encryption Key for the internal storage also has access to the OIK, and has Ownership. By default, that includes all users added after FileVault encryption is enabled on a Data volume, for example.
Apple silicon Macs always start their boot process from their internal storage, even when they’re going to boot from a second operating system stored elsewhere. To be able to boot from that second OS, it requires a LocalPolicy with an OIC attached, and Ownership has to be handed off to an Install User created when that OS is installed. Creating and changing that LocalPolicy thus requires Ownership, for which the same password is required as for access to encrypted internal storage.
Handing off Ownership to the Install User is more of a problem, as users are only created once the installation is complete. To accommodate that, macOS offers to copy a user from the current boot system as the Install User, and the primary admin user, on the second OS. Apple states: “When running an Install Assistant and targeting installation for a secondary blank volume, a prompt asks the user if they’d like to copy a user from the current volume to be the first user of the second volume. If the user says yes, the ‘Install User’ which is created is, in reality, a KEK which is derived from the selected user’s password and hardware keys, which is then used to encrypt the OIK as it’s being handed to the second operating system. Then from within the second operating system Install Assistant, it prompts for that user’s password, to allow it to access the OIK in the Secure Enclave for the new operating system.”
Apple strongly recommends that this offer is accepted, as it ensures that the Install User can access the OIK, and that security is fully preserved. However, if the user decides not to copy the current user, macOS will create an Install User with a blank password.
macOS has a command tool provided for advanced users to work with boot policy and LocalPolicy for security settings on Apple silicon Macs, bputil. Although potentially a dangerous tool, used with great caution and following the guidance in its man page it can sometimes diagnose and fix problems. However, the primary tool for changing boot security on Apple silicon Macs is Startup Security Utility, and unless you really know what you are doing with bputil you shouldn’t even go near it.
Summary
In Unix permissions on all Macs, the owner is the user whose UniqueID is designated as the owner of a file, folder or volume. If there are ownership problems, setting a volume to Ignore ownership can solve them.
On Apple silicon Macs, the owner is a user with access to the Owner Identity Key who can change LocalPolicy for a boot volume, particularly when on an external disk. This is set during installation of that boot volume, and has absolutely nothing to do with Unix permissions.
bputil isn’t a tool for the casual or curious. Before using it, or suggesting that anyone else might use it, read its man page and be forewarned. And remember that it has nothing whatsoever to do with permissions, but boot policy.
The CrowdStrike catastrophe has drawn attention to differences between modern macOS and Windows, and how kernel extensions (kexts) are being replaced in macOS by System Extensions. This article summarises what is changing, and how much progress macOS has made as of Sonoma 14.5.
Kernel space
The XNU kernel at the heart of macOS consists of central systems derived from Mach, BSD and I/O Kit. This runs at the highest level of privilege, in kernel space, often referred to as Ring 0 on Intel systems, although that term isn’t used for Arm CPUs as they have Exception Levels with EL0 as the least-privileged or user space. The kernel provides support for a great many services to interface with hardware and higher-level functions such as network protocols and file systems, that are almost entirely delivered as kexts running in Intel Ring 1.
Currently, in macOS Sonoma there are well over 650 kexts included in the System volume, three third-party kexts including SoftRAID that are in /Library/Extensions, and three that are firmlinked from outside the Signed System Volume (SSV), so they can be updated without creating a whole new sealed system snapshot.
Third-party code that needs direct access to kernel space has in the past used Kernel Programming Interfaces (KPIs) only accessible from kexts. These have included:
I/O Kit drivers, including USB
PCI and Thunderbolt
Serial port drivers
Audio drivers
Network drivers, for network filters
Storage drivers
File systems.
Long and sometimes bitter experience of third-party kexts has demonstrated how their bugs and incompatibilities have resulted in kernel panics, where the kernel has no choice but to force a restart. Those risk losing data, and (in older file systems including HFS+) in leaving the file system in an unstable state, requiring repair. While recent models of Mac will restart rather than just shut down following a panic, the user needs to log back in and clean up before the Mac can be used again. When this happens at scale, as occurred with CrowdStrike, it has major impact.
User space extensions
Instead of delivering access to these features in kernel space using KPIs, macOS is transitioning to access in user space, where third-party code is delivered in System Extensions, running in Intel Ring 3 (Arm EL0). This transition involves Apple providing new and modified system kexts with their replacement interfaces for the System Extension to plug into.
One particularly relevant example is support for Endpoint Security, requiring monitoring of system events to discover potentially malicious activity. In the past this was handled by third-party kexts relying on KPIs, but should now be performed by a client System Extension that registers with Endpoint Security to receive notifications of different types of event, such as processes executing and file systems being mounted. These are documented at length, and are constrained to those events that Apple chooses to expose. If a security software developer wants access to other events, then they have to ask Apple to add them to Endpoint Security.
Deprecation and substitutes
Although Apple has been making discouraging noises about kexts for years, until it provided fully functional alternatives, developers had nowhere else to go and had to stay with kexts and KPIs. Many of those were officially deprecated in Catalina, and in Big Sur kexts using those no longer load by default. Among those affected are:
Various KPIs now available in Endpoint Security
Networking KPIs now available in Network Extensions
IOHID input devices
USB drivers now available in USBDriverKit and USBSerialDriverKit
PCI drivers now available in PCIDriverKit and NetworkingDriverKit.
Network Extensions include changing Wi-Fi configuration, a Hotspot Helper to integrate with hotspots, VPN using built-in and custom protocols, network relaying, DNS configuration, and content filters.
Some replacements have been slower to arrive, and the following are among those made obligatory in Monterey 12.3 and later:
Audio using AudioDriverKit
Bluetooth using CoreBluetooth
SCSI drivers now available in SCSIControllerDriverKit.
One of the last significant features to be transitioned to System Extensions is file system support, coming to user space in Sequoia as FSKit. Although it does now have a little documentation, that reveals that this initial release only supports simple file systems with one volume in each container; support for more sophisticated file systems is coming, but I don’t think Apple has announced when.
Penalties
Intel Macs have no restrictions or security limitations when using kexts, but Secure Boot in Apple silicon Macs won’t load any third-party kexts when run at Full Security. This makes the use of kexts on M-series Macs awkward to say the least. Apple has detailed the process of downgrading security and permitting loading of a kext, involving:
Start up in Recovery mode and select Options.
Open Startup Security Utility.
Downgrade boot security to Reduced Security.
Enable the loading of third-party kexts.
Restart in normal mode, and proceed to install the app with its kext installation steps, involving authorising the new kext in Privacy & Security settings.
Once the kext has been fully installed, and built into the Auxiliary Kernel Collection, restart.
Problems
Just as there are no clear-cut classes of app, kexts don’t all fall into neat groups. Although now widely implemented in some areas, such as Endpoint Security and Network Extensions, in others System Extensions still don’t fully replace KPIs. One good example is SoftRAID, a widely used driver supporting software RAID, which has had to be incorporated into macOS distributions as it still can’t be implemented in user space.
Kits to replace KPIs are also immature. Although I have been evaluating and reviewing products such as Little Snitch and various security suites using Network Extensions and Endpoint Security without encountering any problems, developers complain that support in macOS remains unstable and has vulnerabilities. When there’s a bug in that support, it may result in a kernel panic, causing the problem that this is intended to address.
macOS hasn’t completely replaced kexts yet, but is well on the way to achieving that. The benefits to stability and security are already being realised: I like to have a steady supply of panic logs to use in articles here, but I think the last I experienced was over three years ago, back in Big Sur, the result of a bug in iBoot firmware that has long since been fixed. Maybe I’ll have to start deliberately panicking VMs next. I’ll leave you with what used to be a common sight, lest we forget.
Apple has just released updates to XProtect Remediator security software (Catalina or later), bringing it to version 140, and to XProtect (for all macOS from El Capitan or so) bringing it to version 5270.
Apple doesn’t release information about what security issues these updates might add or change.
XProtect’s Yara definitions have a single change, adding a DOFMVAD signature to its long list of those for MACOS.DOLITTLE.
No new scanning modules are added to XProtect Remediator, and there are no changes to Bastion rules for the behavioural version of XProtect (Ventura and Sonoma only).
You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-140 and XProtectPlistConfigData_10_15-5270.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
XProCheck is one of my unique utilities, to the best of my knowledge the only app that checks whether your Mac has been running its XProtect Remediator (XPR) anti-malware scanner, and reports the results of its scans in full detail. I’m delighted to release a new version of XProCheck that improves both its checks and reports.
Apple introduced XPR two years ago, as a greatly enhanced replacement for its Malware Removal Tool, MRT, which is no longer maintained. XPR is installed on all Macs running Catalina or later, and normally performs two sets of scans, one as the user and the other as root, every 24 hours or so. It currently contains scanning modules for 22 different types of malware, and one to cover those previously included in MRT’s checks. Its scans will not only detect known malware, but will also try to remove (‘remediate’) those that it does detect.
Strangely, XPR doesn’t report detections or remediations to the user, but can report them to third-party security software using Endpoint Protection (Ventura and later). As far as I’m aware, though, few if any security products make use of that, leaving XProCheck as the only way to monitor XProtect Remediator scans and reports.
XProCheck version 1.6 brings one major improvement, in changing the method used to check log entries for XPR’s reports. Previous versions have used the log show command, but this new version now reads the log directly using the OSLog API. Although this does have a small memory leak that would only be significant if you were to run dozens of checks in succession, it brings considerable improvements in speed, particularly when checking scans over longer periods, and on Apple silicon Macs.
This version of XProCheck typically takes less than 60 MB of memory before running any checks, rising to less than 70 MB after it has completed its first check. That may rise by less than 1 MB with each subsequent check made before quitting the app, so is almost unnoticeable.
There are two more cosmetic improvements: XProCheck reports now also give the time of its checks in local time as well as GMT/UTC, and the width of the scanner name field is a little greater, to better accommodate CardboardCutout.
XProCheck version 1.6 runs on all Intel and Apple silicon Macs in all versions of macOS from Catalina to Sequoia betas, and is available from here: xprocheck16-1
from Downloads above, from its Product Page, and through its auto-update mechanism.
Login
