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.
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.
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.
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.
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.
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.
Not content with two different XProtects, Apple added a third to macOS Ventura, XProtect BehaviorService (XBS), part of the new Bastion behavioural-based malware detection system. Rather than performing on-demand or periodic scans of static code, this watches for potentially malicious behaviours, such as attempts to access folders used by browsers such as Safari and Google Chrome. This article summarises what XBS is doing as we prepare to upgrade from Sonoma to Sequoia.
What they do
Apple tells us precious little about XBS and Bastion, mentioning them in its Platform Security Guide: “In addition, XProtect contains an advanced engine to detect unknown malware based on behavioral analysis. Information about malware detected by this engine, including what software was ultimately responsible for downloading it, is used to improve XProtect signatures and macOS security.”
At present, XBS and Bastion only record suspicious events in the XBS database at /var/protected/xprotect/XPdb, report them to Apple, but don’t attempt to intervene in any way. They determine what to report according to a set of rules applied by syspolicyd that are compiled from source files updated inside XProtect Remediator update bundles. Changes in those, in XPR’s scanning modules, and in XProtect’s detection signatures, are reported on this blog for each update released by Apple.
Development
Over the period since its introduction, Bastion rules have grown steadily, from four to 12:
In macOS 13.5 (24 July 2023) there were 4 rules, increasing to 5 in September 2023.
XProtect Remediator (XPR) 108 (8 August 2023) brought the first separate Bastion rule update.
XPR 112 added rules 6 and 7.
XPR 123 added rules 8 and 9, and adjusted rule 7.
XPR 130 added rule 10.
XPR 131 added rule 11.
XPR 137 added rule 12, and amended rules 6 and 7.
Updates provided in XProtect Remediator contain two files for XBS and Bastion:
bastion.sb, a text file containing the latest Bastion SystemPolicyConfiguration, its rules;
BastionMeta.plist, a property list defining behaviour dictionaries for XBS and Bastion.
Bastion rules
The Bastion SystemPolicyConfiguration file bastion.sb is prefaced with the line (version 3), which hasn’t changed since the first update.
This first defines four groups of processes: usual-offenders, common exceptions to several rules, and separate groups of exceptions to each of Bastion rules 1, 2, 3 and 12. For example, com.apple.mds and other Spotlight indexing processes are usual-offenders, while com.apple.Finder is only a rule-one-offender. Interestingly, three of the XProtect Remediator scanning modules (MRTv3, Pirrit and WaterNet) are included in the list of usual-offenders.
Using those lists of exceptions, Bastion rules are then built as filters:
excludes other processes from accessing private data for Google Chrome, Firefox and Safari;
excludes other processes from accessing private data for Messages, Microsoft Teams, Slack and WhatsApp;
excludes other processes from accessing the QuarantineEvents database;
controls access to two socket ioctl commands SIOCIFCREATE and SIOCGIFDESC;
controls access to writing files with a period/stop at the start of their name within Library/PrivilegedHelperTools/ directories.
controls creating or writing to files with a name starting with com within /Library/Application Support/
controls creating or writing to files with a name starting with com within /Library/Application Support/ and user /Library/Application Support/ directories
controls creating or writing to files with a name starting with a period/stop, other than .DS_Store, in user /Library/Application Support/ directories
excludes other processes from creating or writing to files in user /Library/Containers/com.apple.Safari/Data/Library/Safari/AppExtensions/ directories
controls creating or writing to files with a name starting with a period/stop, other than .DS_Store, .betamigrated and .localized, in the /Users/Shared/ directory
controls execution of processes from files with a name starting with a period/stop in the /Users/Shared/ directory
excludes other processes from accessing private data for Notes, Safari Cookies, Chrome, Brave, Microsoft Edge, Opera, Vivaldi, Firefox, Arc, other cookies, Electrum and Coinomi wallets, Exodus, atomic, Binance, Filezilla, Steam and Discord.
The updated bastion.sb file supplied in XPR updates is explicitly referenced by syspolicyd to replace the version embedded in its own code.
BastionMeta.plist
This property list contains a metadata dictionary of 12 behaviours, each correlating with a Bastion rule. Each has a Signature Name, such as macOS.NetworkSniffer.Generic, a Boolean value indicating the need for immediate reporting, and a binary flag ranging from 1 to 2048. The behaviours are named:
Browser
Messages
QntDb
NetworkSniffer
HiddenPrivilegedHelpers
ADLOAD NumericPath
ADLOAD PersistenceSearch
Persistence HiddenAppSupport
Safari ExtensionModification
Persistence HiddenShared Generic
Persistence HiddenShared Exec
InfoStealers.
Behaviours detected
Individual rules currently detect:
attempts to access private browser data
attempts to access private messaging data
attempts to access quarantine records
attempts to perform network packet sniffing
attempts to write to hidden privileged helper apps
Adload behaviours
Adload persistence behaviours
persistence behaviour using hidden files in user /Library/Application Support/ directories
attempts to create and use Safari extensions
persistence behaviour using hidden files in /Users/Shared/
persistence behaviour running hidden files in /Users/Shared/
attempts by an InfoStealer to access a wide range of private data.
Summary
In macOS Ventura and later, XProtect BehaviorService (XBS) and its Bastion rules detect suspicious behaviours that might reflect malicious activity.
Bastion rules are updated within XProtect Remediator updates, using two files bastion.sb and BastionMeta.plist.
There are currently 12 Bastion rules, covering generic behaviours such as accessing private data, to those indicative of Adload and InfoStealer malware.
Suspicious behaviour is recorded locally to the XBS database and reported to Apple, but isn’t notified to the user.
Currently the primary purpose of XBS and Bastion is to provide Apple’s security team with intelligence to improve protection provided by XProtect and XProtect Remediator.
Login
