Archive for the ‘XProtect’ Category

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:

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

February 24, 2013 10 comments

In response to a number of recent Java exploits, both Apple and Mozilla have begun blocking vulnerable versions of Java from running in their respective browsers via their malware protection mechanisms. While this is the right move from a security perspective, it can leave enterprises without the ability to access mission-critical systems that use Java applets running in a browser.

The fix should be to update those affected machines with the latest version of Java. However, this assumes that a) the latest available version of Java is not itself blocked and b) the mission-critical system is able to use the latest version of Java.

From my own perspective, what Apple is doing from a malware protection standpoint is the right thing. I just don’t want my users to lose the ability to access our systems that use a Java applet, especially when the latest available version of Java is blocked and I don’t have a way to otherwise satisfy Apple’s XProtect malware protection without disabling XProtect.

My fix was this: manage XProtect’s ability to disable the Java browser plug-in by modifying the Java browser plug-in settings in the affected Mac’s /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist file. See below the jump for the details.

Read more…

%d bloggers like this: