Last Week on My Mac: What is happening with XProtect updates?

Despite the worst efforts of Elon Musk to destroy everything good that remains of Twitter, it came to my rescue yet again when I recalled a tweet from @L0Psec from 12 June. That had announced a new command tool he discovered in early macOS Sequoia betas that also solved the mystery of what had gone wrong last week in my MacBook Pro’s security data updates.

I hadn’t had time to investigate the new command back in June, but when I noticed that my beta-test system had failed to update to XProtect version 5271 and wouldn’t even offer that update, it occurred to me a tool named xprotect might cast light on this mystery. Sure enough, when it assured me that the update had been installed after all, I could piece together what had happened and search Apple’s release notes unsuccessfully for an explanation. At some time between 23 July when version 5270 was released, and 6 August when it was replaced by 5271, Sequoia’s mechanism for updating XProtect’s data had changed completely without so much as a brief warning.

In that period of a fortnight, XProtect stopped behaving as it had for the last 15 years, since it was introduced in Mac OS X 10.6 Snow Leopard in August 2009. The version number of XProtect.bundle in CoreServices became a relic of the past, and didn’t show that actually installed. Software Update and softwareupdate, which had happily delivered hundreds of previous updates, had now fallen silent about XProtect.

Macs running older versions of macOS still found and installed the latest version, but not those running Sequoia. When it did appear, among the many listed by System Information in Installations, it was named as XProtectCloudKitUpdate, implying it had been downloaded from iCloud using CloudKit. I have later confirmed that obtaining this update doesn’t require the user to be signed in to iCloud, and it has joined the army of maintenance services using iCloud servers.

Updating XProtect in Sequoia

If you’re not using the latest version of SilentKnight, which now does this automatically, you can check the version of XProtect data installed on your Mac using the command
xprotect version

If that or SilentKnight reports an older version than expected, and you want to manually check and install any available update, rather than using softwareupdate, use
sudo xprotect check
Then, if there is an update available, obtain and install it with
sudo xprotect update
both of which will require you to authenticate, as they must be run with elevated privileges.

I am working on a new version of SilentKnight that will save you the trouble of using Terminal to do that. Details of this new command tool xprotect are available in its man page, or from
xprotect -h
although neither explains how this has changed, or why.

Why change?

The early years of XProtect saw emphasis on blocking vulnerable and exploited versions of Adobe Flash Player, and its Yara detection rules developed only slowly. When Adobe finally killed Flash Player at the end of 2020, attention turned to XProtect’s role of detecting and blocking other malicious software when it was first launched.

Its Yara rules grew steadily, as did the size of its XProtect bundle. Version 2109 from 27 September 2019 was 228 KB, and had risen to 2.5 MB by the update to 2178 of 4 January this year. This growth has accelerated lately, and version 5271 released on 2 August reached a total of 3.2 MB. The number of Yara rules contained in that bundle has exploded since the start of this year, with version 2192 on 23 April adding no less than 74 new rules tackling Adload malware, all in a single update.

Releasing new versions through Software Update is a slow and complex process, geared better to low frequencies. Before 2020, XProtect had usually been updated every month, but this year alone there have been 20 updates in less than eight months. Updating XProtects’s Yara rules using iCloud should be quicker, more efficient, and capable of promulgating changes more frequently. Apple could issue new rules as they’re developed and tested, then provide summary updates for Sonoma and older macOS to catch up every 2-4 weeks.

Presumably, these new iCloud updates transfer their payload as binary data rather than verbose Yara text definitions. If they do use CloudKit, then they could directly update a Mac’s security database, much as apps using CloudKit already do, and as used to update notarization data.

Older macOS

Alongside its sibling XProtect Remediator (XPR), XProtect is the front line of Apple’s campaign against malware. XPR was introduced in macOS Monterey two years ago and backported to Catalina and Big Sur. As it’s more of a standalone service, that doesn’t appear to have required much change in those older versions.

This new delivery mechanism for Sequoia is more likely to require internal surgery to security sub-systems, and appears less likely to be offered in Sonoma or Monterey. There are still many Macs running older versions of macOS no longer receiving macOS security updates, and I expect Apple will want to continue offering them more traditional updates for the foreseeable future. Those will also enable security researchers to keep a watch on which malware XProtect can detect using the rules in its Yara file.

Informing beta-testers

I’d like to thank @L0Psec for being the only person to draw attention to what would otherwise have appeared a worrying situation, and to remind Apple of the need to keep beta-testers informed. We’re all keen to keep our test systems well-protected, and should have been warned of this change, and told of the new command tool, rather than hearing about it in the scarred remains of what used to be Twitter. I hope this will be rectified for the next public beta-release, or there could be an avalanche of Feedback reports.

It’s no good telling us that XProtect “uses YARA signatures, a tool used to conduct signature-based detection of malware, which Apple updates regularly”, then those updates are obfuscated.