macOS Sequoia 15.0 brings major change to the maintenance and updating of XProtect’s data. With the release of that new version of macOS, Apple has stopped providing any updates to XProtect data for previous versions of macOS, including the latest updates to Sonoma 14.7 and Ventura 13.7, also released yesterday.

Sequoia

If you have upgraded your Mac to Sequoia 15.0 or 15.1 beta, then it should be using XProtect data version 5273, released yesterday, 16 September 2024.

However, immediately after upgrading, the XProtect version may be given as 0, indicating that there’s no XProtect data installed at all. If that’s the case, or the version shown is 5272 or earlier, open Terminal and type in the following command:
sudo xprotect update
after which you’ll be prompted to enter your admin password. Once you do, the latest version of XProtect data should be obtained and installed correctly.

If you run SilentKnight after upgrading to Sequoia, it may find an XProtect data download waiting to be installed. If it does, install it. However, that doesn’t actually update the data used by this new version of XProtect. To complete that process, use the sudo xprotect update command in Terminal.

If you don’t use SilentKnight, you can check the current version of XProtect data being used with:
xprotect version
That should now return 5273. If it doesn’t, use the sudo xprotect update command to force an update.

Sonoma and all earlier macOS

With the release of Sequoia 15.0, Sonoma 14.7 and Ventura 13.7, Apple’s software update servers have stopped providing XProtect data updates to all versions of macOS prior to Sequoia. I have confirmed this in both Sonoma and Ventura. It’s not clear whether this is an error and Apple intends restoring XProtect updates in the future, or has simply stopped providing further updates.

The effect of this depends on the latest version of XProtect data installed on your Mac. If that’s 5272, then your Mac has the latest available without upgrading to Sequoia. If that’s any earlier version of XProtect, then there’s now no supported way for your Mac to be updated from that old version. As the XProtect bundle is located on the Data volume, you could try manually replacing the bundle (if you can get one for version 5272), but there’s no guarantee that will actually be used by XProtect, or make any difference to the protection it provides.

SilentKnight and Skint

The good news is that, if you use my free SilentKnight, and/or Skint, you should get the best information and help whichever version of macOS is running.

In anticipation of this, current versions of SilentKnight and Skint now report different versions for XProtect data depending on whether that Mac is running Sequoia or an earlier version of macOS. However, if the version found is earlier than 5273 (15.x) or 5272 (14.x and earlier), it will be reported as an issue. If Apple does restore XProtect data updates to macOS 14.x and earlier, then SilentKnight should be able to download and install them.

If your Mac is running Sequoia, SilentKnight can’t (yet) update XProtect data. To do that, you’ll need to run sudo xprotect update in Terminal.

Summary

• The most recent version of XProtect data for Macs running Sonoma or earlier is 5272.
• Currently, Apple’s update servers have stopped providing any updates to XProtect data for Sonoma and earlier.
• Sequoia should be using XProtect data version 5273.
• If your Mac is running Sequoia and has an older version, use the sudo xprotect update command to force an update.

Update

As of about 0530 GMT on 18 September 2024, XProtect updates for macOS Sonoma and earlier are available again, delivering version 5272 through Software Update, softwareupdate and SilentKnight. Fuller details are in a new article coming very shortly.

As promised last week, Apple has released the upgrade to macOS 15.0 Sequoia, together with security updates to bring Sonoma to version 14.7, and Ventura to 13.7. There should also be Safari updates to accompany the latter two.

The Sequoia update is around 6.6 GB for Apple silicon Macs, and 14.7 is around 1.6 GB. For Intel Macs, 15.0 is around 4.9 GB as an ‘update’, and 14.7 is around 860 MB.

Security release notes for Sequoia list around 77 vulnerabilities addressed, including two in the kernel, none of which Apple is aware may have been exploited in the wild. Release notes list 36 vulnerabilities addressed in Sonoma 14.7 here, and there are 30 listed for Ventura 13.7 here.

iBoot firmware is updated to version 11881.1.1, Intel T2 firmware to version 2069.0.0.0.0 (iBridge 22.16.10353.0.0,0), and Safari to 18.0 (20619.1.26.31.6).

After completing the upgrade to 15.0, you are likely to see that the installed XProtect version is 0, in other words that there is no XProtect data. You can leave your Mac to automatically download the required data from iCloud, or manually force it using the command
sudo xprotect update
then entering your admin password. That will normally ‘activate’ the XProtect data previously installed, and set the version to 5272, although that will then need to be updated to 5273 separately. Don’t be surprised if you end up repeating the trip to Terminal to get this to work.

If you use .NET, you may wish to delay upgrading to Sequoia: see this article for further details. Thanks to Raoul for pointing this out.

Last updated 0810 GMT 17 September 2024.

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.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

Some apps may crash when launched because there’s something wrong in the app. In Ventura and later, that might occur because macOS is refusing to run them because of security rules, specifically launch constraints. These were extended in Sonoma to allow any app to limit the code it runs to what should be there, in launch environment and library constraints. This article explains what these are, and how you can recognise when constraints are applied.

Code without constraints

Launching an app without constraints isn’t as unconstrained as that might suggest. It’s still given an environment to run in, with settings such as the user’s Home folder and some standard paths including a temporary folder buried in /var/folders. If you’re interested to see what those can include, Mints has a button to show you its own launch environment.

On top of those, the app is limited by standard permissions as to what it can access without obtaining elevated privileges, and everything is subject to the privacy restrictions imposed by TCC according to the app’s Privacy & Security Settings.

But the app can be run from pretty well anywhere, and can run code from libraries, frameworks and other places as it wishes.

Launch constraints

The first set of launch constraints became obvious if you tried to copy and run from a different location one of the apps bundled in Ventura. This has had its purposes in the past, for example to run Network Utility after Apple first gutted then removed it. Try that with one of Ventura’s bundled apps, and the copy can’t be run from any location apart from the SSV it’s installed in, as it crashes immediately. Look in its crash report and you’ll see something like
Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid))
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: CODESIGNING 4 Launch Constraint Violation

That’s given in a bit more detail in the main log, for Terminal as
AMFI: Launch Constraint Violation (enforcing), error info: c[1]p[1]m[1]e[2], (Constraint not matched) launching proc[vc: 1 pid: 2440]: /Users/hoakley/Documents/00crypt/Terminal.app/Contents/MacOS/Terminal, launch type 0, failure proc [vc: 1 pid: 2440]: /Users/hoakley/Documents/00crypt/Terminal.app/Contents/MacOS/Terminal
ASP: Security policy would not allow process: 2440, /Users/hoakley/Documents/00crypt/Terminal.app/Contents/MacOS/Terminal
xpcproxy exited due to OS_REASON_CODESIGNING | Launch Constraint Violation, error info: c[1]p[1]m[1]e[2], (Constraint not matched) launch type 0, failure proc [vc: 1]: /Users/hoakley/Documents/00crypt/Terminal.app/Contents/MacOS/Terminal

The same happens if you try running a forbidden command, such as /usr/libexec/periodic-wrapper.

Open the app using Apparency and view its Launch Information, and you’ll see the launch constraints that caused this.

For the Chess app, those read
(on-authorized-authapfs-volume or on-system-volume ) and launch-type = 3 /* CS_LAUNCH_TYPE APPLICATION / and validation-category = 1 /* CS_VALIDATION_CATEGORY_PLATFORM */
which should give you a good idea that app can only be run from its standard location in the SSV or System volume. To make this even harder, Sonoma’s Finder tries to stop you from even copying bundled apps to other locations, and you now have to be ingenious to try launch constraints out.

Launch constraints were first described by Csaba Fitzl, and he has since compiled a listing of all those known. Those shown for Chess.app are Category 14, and common to other bundled apps. Their effect is to prevent all copies of that app from being launched from elsewhere.

Trust caches

Instead of macOS looking up each binary’s launch constraints from the binary itself, all those constraints are assembled into Trust Caches, where they’re listed by the code directory’s hash (cdhash). To look up the launch constraints for the Terminal app, the system first calculates the cdhash for its code directory, then looks in the Trust Cache for the launch constraints given for that cdhash.

The System volume contains a static Trust Cache that covers all the executable binaries that come as part of the system. That’s locked into read-only storage during the early kernel boot phase of startup. Additional Trust Caches are authenticated to ensure they haven’t been tampered with, and loaded when required. Apple cites the example of the Trust Cache required by the code within macOS software updates (known as the update brain) that runs the process, allowing it to run with platform privileges, as it requires to perform the update. Apple gives further details on Trust Caches in its Platform Security Guide.

Disabling launch constraints

What if you need to ignore those launch constraints imposed by macOS? Because system executables are laid out in the static Trust Cache, there’s no way to modify that, and no way to override it. All you can do is disable System Integrity Protection (SIP), which is required for launch constraints to operate.

Environment constraints

Launch constraints and the Trust Cache system are complete and fully enforced as of Ventura 13.3, and have been extended for use by third-parties in Sonoma. Developers can build dictionaries containing facts and applying operations to them to improve the security of their apps. Constraint dictionaries are either saved in property lists for launchd, or in those used for signing code. These too are associated with cdhashes, use some categories common to other trust caches, and work similarly to protect third-party code such as helper apps.

While they might appear overkill, they can be used to address known security problems, of which the most prominent must be maintaining trust with privileged helper apps and XPC services, which have often proved weak points in app security. Apple provides two detailed articles, one explaining how to define these constraints, the other how to apply them. I suspect that we’ll be seeing more of these in the future.

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.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

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.

Last updated 1845 GMT 7 August 2024.

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.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

Apple has just released the update to bring Sonoma to version 14.6, together with security updates to Ventura (13.6.8) and Monterey (12.7.6). I expect that there will also be a separate update to Safari for Ventura and Monterey.

The 14.6 update is around 2.2 GB for Apple silicon Macs, and 1.8 GB for Intel models.

iBoot firmware for Apple silicon Macs is updated to version 10151.140.19, firmware of Intel Macs with T2 chips is updated to version 2022.140.5.0.0 (iBridge: 21.16.6074.0.0,0), and Safari to version 17.6 (19618.3.11.11.5).

Significant bugs fixed include app crashes when running iPhone and iOS apps on Apple silicon Macs, and a complex bug in video decoding in which the hardware decoder wasn’t used when it should have been.

Security release notes for Sonoma reveal a total of 54 vulnerabilities have been addressed, including several in open source code, but none is reported as having been known to be exploited yet. Those for Ventura list 36, and for Monterey 32.

I’ll update this article with further details as they arrive.

Last updated 2142 GMT 29 July 2024.

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.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

Hot on the heels of the slightly earlier update to XProtect, Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 139.

Apple doesn’t release information about what security issues this update might add or change. There are no new scanning modules, and 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-139.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.