Archive for the ‘XProtect’ Category

Codesigning, untrusted certificate authorities and why certain apps aren’t launching

August 24, 2021 4 comments

A number of folks noticed that certain older applications they use on macOS stopped working as of August 24th, 2021. As of this date, this appears to affect the following applications among others:

Note: This list is not complete, it’s just the ones I’m aware of as of August 24, 2021.

Why this is happening goes back to an episode in 2018, where Symantec had to get out of the PKI certificate issuing business because of a number of issues discovered with how Symantec had been issuing certificates.

As part of these issues, Apple issued an advisory that a number of Symantec Certificate Authority (CA) root certificates were to be distrusted by Apple on a timeline which concluded with the full distrust of Symantec CAs on February 25, 2020.

While this primarily affected website operators, Symantec also issued certificates from the affected Symantec CAs which were used to provide code signing for applications. An example of this is RSA SecurID Software Token 4.2.1.

Update 8-26-2021: RSA has released RSA SecurID Software Token 4.2.2 to resolve the issue with RSA SecurID Software Token 4.2.1. For more details, please see the link below:

In the case of SecureID, this app relies on Qt Core for user interface support and ships copies of the QT Core framework along with the SecureID app. SecurID stores this in the following location:


If you take a look at the installer, you can see where the files are supposed to go.

Screen Shot 2021 08 24 at 6 25 25 PM

However, the actual file which is causing the issue is buried further down in the following location:


Screen Shot 2021 08 24 at 6 27 36 PM

This file is important because the QT Core framework is shipped without Apple’s code signing, which is to say that QT is not using an Apple Developer ID signing certificate to sign QT Core. Instead, QT ships a code signing certificate chain and that information is stored in the QtCore.cire file.

One of the certificates in the code signing certificate chain is using VeriSign Class 3 Public Primary Certification Authority – G5 as its root certificate authority (root CA). That root CA is one of the Symantec CAs which is no longer trusted by Apple.

Screen Shot 2021 08 24 at 6 03 58 PM

To summarize: the SecureID app has a component which is signed by a not-trusted certificate. This is causing SecureID to not trust that component, which then prevents the app from launching correctly.


Why is this happening now?

Apple released updates on August 23, 2021 for both XProtect (now version 2150) and Malware Removal Tool (now version 1.82). My assumption is that XProtect’s update included instructions to no longer accept code signing from the distrusted Symantec CAs. XProtect checks executable code on launch, so it would be working with Gatekeeper to detect and block the no-longer-trusted code signing.

What should you do?

See if your vendor has released an updated version of the app which is having problems. If they haven’t yet, I recommend contacting them to make sure they’re aware of the problem.

Hat tip to all the folks working on this issue in the MacAdmins Slack for helping diagnose the issue and why it is happening.

Checking if Apple’s Zoom remediation update has been installed on your Mac

July 12, 2019 Leave a comment

As part of the Zoom vulnerability issue, further problems have been discovered as security researchers look into the local webserver installed by older versions of the Zoom app for macOS.

Apple has moved quickly and released an update to MRT (Malware Removal Tool) which addresses the issue by removing the local webserver. This update has the following version number:

The installer package receipt associated with it is the following:

To verify that you have this installed, here’s a one-line command to check for the latest installed MRT installer package:

printf "%s\n" $(pkgutil –pkgs=".*MRT.*") | sort -k1 | tail -1

view raw


hosted with ❤ by GitHub

To verify that does install, here’s a one-line command to get the version number from the latest installed MRT installer package receipt:

pkgutil –pkg-info-plist $(printf "%s\n" $(pkgutil –pkgs=".*MRT.*") | sort -k1 | tail -1) | plutil -extract pkg-version xml1 – -o – | xmllint –xpath 'string(//plist/string)' –

view raw


hosted with ❤ by GitHub

To assist with getting information like this for Gatekeeper, MRT and XProtect, I’ve written a script that pulls the following information for each:

  • Version number
  • Installation date
  • Installer package receipt identifier

For more information, please see below the jump.

Read more…

Checking XProtect and Gatekeeper update status on Macs

March 28, 2016 10 comments

As part of making sure that XProtect and Gatekeeper are providing up-to-date protection, it can be worthwhile to see when your Mac received the latest updates from Apple for both XProtect and Gatekeeper. As both are background processes, as well as also receiving Config Data updates silently in the background, it’s not always obvious when updates have been applied.

To assist with this, I’ve written a couple of scripts to report the last time that Gatekeeper and XProtect have been updated on a particular Mac. For more details, see below the jump.

Read more…

System Integrity Protection and the end of XProtect management for browser plug-ins

September 14, 2015 13 comments

OS X El Capitan adds a new security feature named System Integrity Protection (SIP). Among other things, SIP prevents parties other than Apple from adding, deleting or modifying directories and files stored in certain directories:

  • /bin
  • /sbin
  • /usr
  • /System

Apple has indicated that the following directories are available for developers to access:

  • /usr/local
  • /Applications
  • /Library
  • ~/Library

All directories in /usr except for /usr/local are protected by SIP.

SIP’s protection of /System affects XProtect’s XProtect.plist and XProtect.meta.plist configuration files as they are stored in the following location inside /System:


As the XProtect configuration files will be locked against editing on OS X El Capitan, this means that they can no longer be managed to allow older versions of the Flash and Java browser plug-ins to run.

If your shop includes a mission-critical system that requires using older Flash or Java browser plug-ins, I recommend working with your vendor and/or in-house developers to find out:

  1. If the use of the Java and/or Flash browser plug-ins can be discontinued.
  2. If their use can’t be discontinued, if the system in question can be updated to support the latest versions of these plug-ins and continue to be compatible as new versions of the Java and/or Flash browser plug-ins are released.

Update – 9-14-2015: Josh Dyson has pointed out that there is a way to allow older plug-ins to access specific sites.

By adding the needed sites to a whitelist in Safari and setting those specific sites to Allow Always, those sites’ functions will be accessible with the older browser plug-in even if XProtect would otherwise block the use of the plug-in. Websites not included in the whitelist would still have the use of the plug-in blocked.

Screen Shot 2015-09-14 at 8.20.10 PM

Apple has provided a KBase article showing how to manage Safari plug-in options, including how to whitelist websites, using a configuration profile. It’s available via the link below:

Managing automatic installation of ConfigData and security software updates on Yosemite

December 27, 2014 2 comments

As mentioned previously, the updates for XProtect’s blacklist moved into Apple’s software update feed starting in Mavericks. Gatekeeper updates are also included in the software update feed on Mavericks and Yosemite, so both XProtect and Gatekeeper updates are being delivered to machines using the same delivery mechanism.

To help distinguish Gatekeeper and XProtect updates from other updates in the software update feed, Apple marks them as being ConfigData updates. For more details on this and how you can manage their automatic installation, see below the jump.

Read more…

Managing OS X’s automatic security updates

December 24, 2014 2 comments

On Monday, December 22nd, Apple released OS X NTP Security Update 1.0 to fix a vulnerability in ntpd. What caught many folks off-guard was that this update installed itself in many cases, without action or authorization by the human using the Mac in question.

Security Update Installed notification

This marked the first time Apple has used its capability to push and automatically install an OS X security update, though the actual capability has been in OS X since OS X 10.8.x. Apple has used a similar capability in OS X 10.9.x and later to push updates for Apple’s XProtect and Gatekeeper.

So how did Apple make OS X NTP Security Update 1.0 install automatically? See below the jump for more details.

Read more…

Forcing XProtect blacklist updates on Mavericks and Yosemite

December 17, 2014 3 comments

One of the changes Apple made between Mountain Lion and Mavericks was how XProtect was updated. On 10.6.x – 10.8.x, Apple used /usr/libexec/XProtectUpdater to update XProtect’s blacklist. If you needed to force XProtect to update, you could run the following command with root privileges:


Running that command with root privileges would force a check-in with Apple’s XProtect feed. If XProtect needed an update, running this command would check the current XProtect blacklist, detect that the online version was newer and pull down the new version. Once the new version had downloaded, XProtectUpdater would then exit.

Screen Shot 2014-12-17 at 10.40.35 AM

If XProtect was up to date, running this command would check the current XProtect blacklist and detect that the online version was the same as what was currently loaded on the system. XProtect would then produce a notification that it was ignoring the update because the online version was not newer than the one already on the system. XProtectUpdater would then exit.

Screen Shot 2014-12-17 at 10.39.36 AM

In 10.9.x and continuing on in 10.10.x, Apple moved the XProtect updates into Apple’s software update feed. As part of this change, the previous way of forcing XProtect by running /usr/libexec/XProtectUpdater no longer worked because /usr/libexec/XProtectUpdater did not exist on 10.9.x and higher.

Screen Shot 2014-12-17 at 10.27.07 AM

Instead, you now need to use the softwareupdate command to force the update process. For more details, see below the jump.

Read more…

XProtect updated – now blocking Java browser plug-in versions prior to June 2013 Java updates

August 29, 2013 4 comments

Apple put out two advisories on August 29th about Java:

Java updates available for OS X on August 28, 2013

OS X: Java Web plug-in blocked 28 August 2013

The latter advisory is especially noteworthy to Mac admins, as that means that Apple’s XProtect was updated to block older versions of Java. That said, XProtect was not updated after the latest round of updates in June 2013, so those versions were not previously set in /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist as the minimum allowed versions. See below the jump for more details.

Read more…

Changes to XProtect’s Java browser plug-in version management

May 11, 2013 3 comments

In last night’s XProtect update, Apple added two new version checks. The first new check looks for Apple’s Java browser plug-in identifier. This Apple Java browser plug-in is running on Mac OS X 10.6.x or was installed on 10.7.x or later by Java for OS X 2012-005 or earlier. Installing Java for OS X 2012-006 and later on 10.7.x and 10.8.x automatically removes the Apple Java browser plug-in.

The second new check looks for Apple’s Java browser plug-in identifier. In this case, the Apple Java plug-in was re-enabled using the procedure in the following Apple KBase article:

This update also removes the Oracle Java browser plug-in version check from 10.6.x’s XProtect. Both new Apple Java version checks and the Oracle Java browser plug-in version check are in the 10.7.x and 10.8.x XProtect. See below the jump for the details.

Read more…

Managing Adobe Flash browser plug-in settings for Apple’s XProtect malware protection

March 8, 2013 4 comments

As a follow-up to my earlier post about managing XProtect’s ability to block Java browser plug-ins , a Mac admin named scifiman sent me a launchdaemon and script to manage Adobe Flash using a similar method. Thanks, scifiman!

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">


# This script is a modified version of rtrouton's re-enable_java_6_and_7 script.
# This script will check the current Adobe Flash browser plug-in
# version and compare it against the minimum version allowed by
# Apple's XProtect malware protection. If the minimum Flash version
# allowed by XProtect does not allow the current version of the Flash
# browser plug-in on the Mac, the script will alter the Mac's
# /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
# file to set the minimum version allowed to match the current version
# of the Mac's Flash browser plug-in. This allows the Mac's current Flash
# browser plug-in to run in Safari without being blocked.
# Original script is from here:

osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

# javaVendor=`/usr/bin/defaults read "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info" CFBundleIdentifier`

CURRENT_FLASH_BUILD=`/usr/libexec/PlistBuddy -c "print :CFBundleShortVersionString" /Library/Internet\ Plug-Ins/Flash\ Player.plugin/Contents/Info.plist`
XPROTECT_FLASH_BUILD=`/usr/libexec/PlistBuddy -c "print :PlugInBlacklist:10:com.macromedia.Flash\ Player.plugin:MinimumPlugInBundleVersion" /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist`

# Check to see if Xprotect is blocking Adobe's Flash browser plug-in and re-enable the plug-in if needed.
# Changes in this section are from Pepijn Bruienne's re-enable_java_6 script:

if [[ -e /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist ]]; then


	 	  /usr/bin/logger "Current Flash build (${CURRENT_FLASH_BUILD}) does not match the minimum build required by Xprotect (${XPROTECT_FLASH_BUILD}). Setting current version as the minimum build."
	 	  /usr/libexec/PlistBuddy -c "Set :PlugInBlacklist:10:com.macromedia.Flash\ Player.plugin:MinimumPlugInBundleVersion $CURRENT_FLASH_BUILD" /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
	 	  /usr/bin/plutil -convert xml1 /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
	 	  /bin/chmod a+r /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
	 	  /usr/bin/logger "Current Flash build is ${CURRENT_FLASH_BUILD} and Xprotect minimum build is ${XPROTECT_FLASH_BUILD}, nothing to do here."

exit 0

The script has been tested on 10.6.8, 10.7.5 and 10.8.2, so it should cover all current OSs that use Apple’s XProtect malware protection.

Scifiman’s original gist is available here:

I’m hosting a copy of the script and launchdaemon here on my GitHub repo:

%d bloggers like this: