If your Mac is still running Sonoma or Ventura, and you have already updated it to 14.7.1 or 13.7.1, you might have noticed that neither updated Safari, nor has there been a separate update released yet for Safari 18.1.
According to release notes for Safari 18.1 (20619.2.8), this new version has already been released for Sonoma and Ventura, but as of 1600 GMT on 29 October 2024, there’s still no sign of any separate update, nor was it bundled in the x.7.1 updates.
Sonoma and Ventura had Safari 18 released for them on 16 September 2024, concurrently with Sequoia 15.0. On 3 October 2024, at the same time that Apple released Safari 18.0.1 in Sequoia 15.0.1, it also released Safari 18.0.1 for Sonoma and Ventura, without any CVEs being reported as fixed.
Current versions of Safari read:
in Sequoia 15.1 – Safari 18.1 (20619.2.8.11.10)
in Sonoma 14.7.1 – Safari 18.0.1 (19619.1.26.111.11, 19619)
in Ventura 13.7.1 – Safari 18.0.1 (18619.1.26.111.11, 18619)
leaving the latter two due an update to Safari 18.1, which would ordinarily have been released with the x.7.1 macOS updates, but hasn’t been yet.
Update
As of 2150 on 29 October 2024, both Safari updates are now available through Software Update. Version and build numbers are 18.1 (19619.2.8.111.5, 19619) for Sonoma 14.7.1, and 18.1 (18619.2.8.111.5, 18619) for Ventura 13.7.1, and Apple lists the CVEs they address in this note.
As expected, Apple has released the update to macOS 15.1 Sequoia, together with security updates to bring Sonoma to version 14.7.1, and Ventura to 13.7.1. There should also be Safari updates to accompany the latter two.
The Sequoia update is around 2.9 GB for Apple silicon Macs, and about 2.4 GB for Intel models.
As expected, this brings the first release of Writing Tools, in the first wave of new AI features, only for Apple silicon Macs using US English as both their primary language, and that set for Siri. Apple hasn’t got round to providing any list of new or changed features, and you may find that offered by Software Update is the same as for 15.0.
iBoot firmware on Apple silicon Macs is updated to version 11881.41.5, T2 firmware to 2069.40.2.0.0 (iBridge: 22.16.11072.0.0,0), and Safari to 18.1 (20619.2.8.11.10).
I will post details of changes found later tonight.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 147. The previous version was 145.
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 Sequoia available from their product page. If your Mac has not 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 XProtectPayloads_10_15-147.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
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.
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.
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.
Login
