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.
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:
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.
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.
There has been a recent outcry over one quietly mentioned change coming in macOS Sequoia, making it harder to run apps that haven’t been notarized by Apple. As there’s some confusion as to exactly what’s going on, this article explains how this should work, and what benefits notarization brings in return for this added inconvenience.
How it used to work
Although Apple has required developers to notarize their macOS apps for several years, starting back in Mojave 10.14.5, it has so far done little to enforce this requirement, except in special cases such as kernel extensions. The first of my free apps to be notarized was LockRattler, back at the end of July 2018, over six years ago, when Apple referred to making notarization obligatory at some time in the future.
In Sonoma and earlier, any app that hasn’t been notarized, but has been quarantined because it has been downloaded from the internet (or a similar cause), won’t open first time from a normal double-click. Instead the user has to select the Open command from the Finder’s contextual menu, resulting in a dialog giving the user the choice of opening the app in spite of it not being notarized and ‘checked for malicious software by Apple’. Once that first run has been completed successfully, no further prompts result, and the app runs normally thereafter.
How Sequoia will work
Changes are only enforced on apps that have been quarantined because of the way they arrived on that Mac. If an app doesn’t have a quarantine extended attribute with the quarantine flag set, although notarization is still checked by Gatekeeper, the app is allowed to run without any additional action by the user. This also allows you to continue to build your own apps locally, sign them using ad hoc certificates, and run them as before. Where this could get more inconvenient is with modes of transfer such as AirDrop that do put apps into quarantine, although they may not have been outside your local network.
Gatekeeper will then refuse to run for the first time those apps that aren’t notarized, if they’re in quarantine. The only way that you’ll then be able to launch an unnotarized app is by adding it to a list of exemptions using Privacy & Security settings. That’s performed on an individual basis, per app, as Apple has now announced to developers.
None of this applies to apps supplied by Apple, or third-party apps supplied through the App Store, which are signed by Apple, not notarized, and aren’t quarantined.
There are two main ways to circumvent this process.
You could strip the quarantine extended attribute before trying to run the app for the first time. This is a potentially dangerous workaround, as it bypasses first run checks that could spot malware. For those of us who often transfer our own apps for testing using AirDrop, it’s easy to drop them into a folder, Zip that, then on the recipient Mac strip the quarantine xattr before unZipping the archive. My utility Cormorant can make that even simpler. If you were to opt to do that, you must be absolutely certain of the provenance of the app you’re transferring.
For those who have test systems that frequently need to run unnotarized apps, another potential solution is to disable Gatekeeper on them. Perhaps anticipating a move to do that, Apple has changed how this can be done, making it a two-step procedure, in which you first allow the disabling of checks, then in Privacy & Security settings control how that is implemented. Apple encourages those who need to do this to use installed profiles instead, or handle it through MDM payloads. This has been explored in detail by Brandon Dalton in his account of these changes.
I’m frequently surprised to learn how many Mac users have disabled Gatekeeper checks in the past and forgotten to reinstate them, only to be reminded when they later run SilentKnight for the first time.
There’s also a third method that’s little-known, although in the early years of notarization it was practised widely, and that’s notarizing other developers’ apps. Apple has made it clear that submission of an app for notarization doesn’t have to be performed by its developer, the owner of the certificate used to sign the app with, but anyone with a current developer account with Apple can do so provided they follow the correct process. This is most appropriate for those in enterprise and organisations who need to use third-party products that aren’t yet notarized by their developer.
Why notarization?
Superficially, notarization brings two obvious benefits, in apps being checked for malware by Apple before they’re issued a notarization ticket, and in the ‘hardened’ runtime they’re required to adopt to qualify for notarization. Those remain controversial; in the past some malware was apparently notarized, although that seems to have resulted in more stringent checks being applied. But those overlook its greatest benefit.
Code-signing used to be considered an effective way of ensuring the integrity and provenance of executable code, but has now become too low a bar to be effective. It’s all too easy to strip a signature and resign code, and in any case acquiring developer certificates is neither expensive nor difficult. Although Apple does revoke certificates promptly once their abuse is detected, the interval between first abuse and revocation is often sufficient for most who develop malware. Once one certificate has been revoked, it’s then easy to move on and use another, always keeping one step ahead of Apple.
In recent versions of macOS, executable code is recognised and managed using its cdhashes, a tree of hashes of its components within a bundle, for instance. A notarization ticket contains cdhashes that have been accepted by Apple as a record of that app when it underwent notarization. To verify the integrity and authenticity of any notarized code, all macOS has to do is compare freshly computed cdhashes against those provided in the app and its ticket, and against those in Apple’s notarization records. This presents a much higher bar to those trying to masquerade as or tamper with notarized executable code.
By making it harder for a user to run unnotarized code, the chances of that user inadvertently running malicious code are considerably reduced.
Login
