Apple’s pushed update to XProtect’s data a couple of days ago is one of the most substantial since the tool was introduced, adding over a hundred new items to its detection lists. With Catalina looming, I think it’s time to reassess what XProtect actually does.

According to Apple’s latest macOS security overview:
“macOS includes built-in technology for the signature-based detection of malware. Apple monitors for new malware infections and strains, and updates XProtect signatures automatically — independent from system updates — to help defend Mac systems from malware infections. XProtect automatically detects and blocks the installation of known malware.”

That describes in a nutshell what XProtect has done, for example back in El Capitan and Sierra. Its data, located inside /System/Library/CoreServices/XProtect.bundle/Contents/Resources, consists of three files:

• XProtect.meta.plist, a property list (XML) file specifying minimum versions of Internet Plugins like Flash, a Safari extensions blacklist, and a short list of code signature IDs used by Apple;
• XProtect.plist, a property list (XML) file containing a blacklist of known malware signatures;
• XProtect.yara, a set of ‘Yara’ rules for detecting items in XProtect.plist using signatures such as hashes.

This latest update to these files added 101 new Safari extensions to the blacklist in the first of these. This large number suggests that Apple has been compiling a list of the many malicious and unwanted extensions, and coincides with changes in the way Safari works with extensions, including discontinuation of the old extensions mechanism. For each extension, the property list contains a bundle identifier like com.enginereader4636, and the identifier of the developer associated with that, in this case NQKWW269GU.

This update therefore brings great improvements to the blacklist of Safari extensions which should be blocked by macOS.

But XProtect may have a greater role in the future, with Catalina in particular. Each time that you open an app in Catalina, it is scanned by XProtect for malware. If all that does is look for the traditional old malware products by signature, then it’s hard to see that it’s worth the effort. Catalina, like Mojave, is also going to be checking which apps are hardened and notarized.

To date, Apple has only disclosed how notarization is required when a quarantined app is first run. There’s another feature of the notarization system which hasn’t been covered in any detail: how it can be used to revoke not whole developer certificates, but specific versions of an individual app. Because Apple’s notary service checks and approves a specific build and release of an app, those approvals can also be revoked on the same specific basis, a feature which Apple has used in its advocacy of notarization in macOS security.

Under the old signature system, the many purely local signature checks performed for various reasons refer to your Mac’s local Gatekeeper database to determine whether any given developer certificate has been revoked. That database is updated periodically, usually every week or two. For similar checks to be made on notarization, macOS is likely to need a local database of revoked notarizations too. If notarization is only to be checked when a quarantined app is first run, then revocation is going to be of no benefit to those copies of the app which have already cleared their first run.

It will be interesting to see what role XProtect has in the future, and how it is beefed up to do more than just run through old Yara rules for malware of the past. For the moment, though, we only have evidence that it is now more effective at protecting Safari from a large number of malicious and unwanted extensions.