Last Week on my Mac: I told you so

One of my greatest regrets in life is that I never invested in a stock of cards with just four words on them: I told you so. Although I’m often wrong, when I see an obvious problem on its way, it’s disappointing how often it’s ignored. Instead of last week being all about Sequoia, I ended up spending most of my time trying to discover what the hell was going on with XProtect and its updates.

My feeling of unease started before last weekend. My fourth and last-ditch fallback Mac is a lovely MacBook Pro 16-inch 2019. It doesn’t see much use, so in the days before the release of Sequoia I charged it up and updated it to 14.6.1. It was still running an old version of XProtect, 2195 from the end of May, so I was surprised when it didn’t update XProtect, and no update was offered. At roughly the same time, my MacBook Pro M3 Pro running 15.1 beta updated from 5272 to 5273, and other beta-testers reported the same.

Bearing in mind that Apple had told nobody what was going on with XProtect or its updates, when last Monday came and my three other Macs that had been running 14.6.1 were upgraded to 15.0, I was still none the wiser. As with everyone else upgrading to Sequoia, any existing XProtect bundle was ignored by the new version of XProtect, and when asked what version of its security data it was running, it replied 0 (zero), indicating that it had no such data. That was a surprise to many, and something not anticipated by any information from Apple.

If you weren’t using SilentKnight, you’d then have to guess either that macOS would somehow fix that before you ran any newly downloaded apps, or that there would be a new command tool named xprotect, whose man page also doesn’t provide any guidance as to what to do.

For those who checked their new Sequoia installation with SilentKnight may have been just as surprised to see the XProtect version of 0, but at least they were guided to run the xprotect command tool, and force an update. Even then, confusion reigned when some Macs were updated to 5273 while others were left at 5272. Either has got to be better than 0, though.

Meanwhile, those who had updated to 14.7 or 13.7 got no XProtect update at all. If those Macs had already installed 5272, then that’s where they stayed, with no sign of 5273, which appeared exclusive to those who had ventured up to Sequoia. But if those Macs were still using an older version of XProtect’s data, there was no update available to take them to 5272, which others had installed when it had been released at the end of last month (28 August).

By the end of the following day, 17 September, this was the state of play with XProtect data:

those running Sequoia could have no XProtect data at all (‘version 0’), 5272, or 5273;
those running Sonoma 14.7 or any earlier version of macOS could have 5272 if they had updated before 13 September, or any older version if they hadn’t.

Then late on 17th, or early on 18th depending on your time zone, everything changed again. Apple’s software update servers started offering 5272 to everyone, and as an added bonus, those running Sequoia might also be offered 5273, although the new iCloud update service seemed content just to offer 5272. Within 24 hours, Apple released yet another XProtect data update, to version 5274, only this time it wasn’t made available to Macs running Sequoia. By the end of 18 September, the state of play had changed to:

those running Sequoia could have no XProtect data at all (‘version 0’), 5272, or 5273, but not 5274;
those running Sonoma 14.7 or any earlier version of macOS could have 5274 if they had updated on 18 September, or any older version except 5273 if they hadn’t.

Does any of this make a difference, though: just what came in the updates to 5273 and 5274?

For Macs running macOS Sonoma or earlier, 5274 is just a renaming exercise, and doesn’t materially affect XProtect’s ability to detect malware. Perhaps it was a placebo after all.

The new Yara definitions added to 5273 are very different, though. As I described in my announcement here: “This adds Yara definitions for MACOS.DOLITTLE.CT, MACOS.SHEEPSWAP.CT and MACOS.SOMA.CT using a new format of rule, with each rule given a UUID and listing SHA256 hashes of file size.” Here’s a short excerpt:
rule XProtect_MACOS_SOMA_CT
{
meta:
description = “MACOS.SOMA.CT”
uuid = “DA584E59-A152-4E5B-A906-D354144DCA69”

condition:
hash.sha256(0, filesize) == “59e01f6f925af0643f4751191d28eab11ffb014412cd66ece8e5c77ba082977a” or
following which are a further 3,123 hashes, whereas MACOS.DOLITTLE.CT has just six.

Clearly, Sequoia’s XProtect is quite a different beast from that in Sonoma. It looks like Apple has forked XProtect data files, the Yara definitions in particular. It’s now likely that each future XProtect data update will either be destined for Sonoma and earlier, or specifically for Sequoia. Keeping them in the same version numbering sequence is only going to lead to greater confusion, unless Apple only intends releasing further updates for macOS 15 and later.

As Apple continues to provide absolutely no information about this, I fear that we’re just going to be left stumbling on in the dark, wondering what’s going on with one of the primary security defences in macOS. It must be time to order a new batch of I told you so cards.