I’ve been thinking more about Apple’s Xprotect Updater mechanism in light of the recent updates that have disabled Java web plugins. See yesterday’s post, for example.
In many enterprise environments, admins choose to run their own Software Update server to provide Apple updates. This is done for several reasons. One is to save bandwidth — it’s more efficient for a single machine to download available Apple updates over your Internet connection, then have all the other machines get those updates over the local LAN.
But another reason is to be able to control which updates are offered to your managed computers. Apple may offer an update that causes issues in your organization. For example, we did not deploy the “Java for OS X 2012-006” update in our environment because it disabled the Java 6 Web Plugin, which we needed.
Yesterday’s Xprotect update essentially did the same thing, this time over a wider range of machines. I quickly put together a workaround, but one of the things the workaround does is to turn off the automatic updates of the XProtect data.
After thinking more about the ramifications of this, I think that this is exactly what most enterprise sites should do. They should treat this update mechanism like all other update mechanisms. I think you should turn this off on most or all of your managed machines.
“But wait,” you are thinking. “Isn’t this risky? Apple is trying to protect users from malware.” If you only turned off the update mechanism on all your machines and did nothing else, you are adding risk. But what you should do is something similar to what an admin that vets Apple Software Updates (or third-party application updates) does before releasing them.
You should enable the update mechanism on an admin machine. When there are new XProtect.meta.plist and/or XProtect.plist files, you should test to see that they don’t cause any issues in your organization, modifying them if needed. You can then use your favorite software deployment system (I like Munki) to distribute these files to your managed machines.
In this way, your managed machines can still get the benefit of updates to Apple’s malware protection mechanism without risking that a component vital to your organization will be blocked without warning.
Managing OS X 
I manage about 3,000 Macs across the country. About half of them use an internal Apple server to get their Apple updates. Are you saying that the users being “managed” by the internal server only didn’t get the XProtect software downloaded to their Macs? I’m receiving a lot of mixed information on that both on the web and from internal users.
I would just like to add that this update should have gone out through the regular channels and gave use a choice. Also, the fact that Apple released this without a newer version available makes me think it was a timing mistake on their part.
“Are you saying that the users being “managed” by the internal server only didn’t get the XProtect software downloaded to their Macs?”
No, I’m not saying that. The XProtect update mechanism is separate from the Apple Software Update mechanism.
“the fact that Apple released this without a newer version available makes me think it was a timing mistake on their part.”
I don’t. I think it was a judgement call that the risk of leaving known vulnerable plugins active was too great. You and I can disagree, and that’s why enterprise admins should start managing this themselves instead of deferring to Apple’s judgement.
If I have to run around and change 1000’s of Macs and turn off Automatically update safe downloads list, then what happens if Apple releases something that we do need? Also if I do that I own the problem if it ever needs to be turned back on.
This “protection” has knocked out production systems across the globe within the Corporation I work for. It will cost untold amounts of money in down time while we debate how to handle this moving forward and Apple’s only solution is to turn Java 6 back on and open up the problem all over again. This is totally irresponsible on Apple’s part.
“If I have to run around and change 1000′s of Macs and turn off Automatically update safe downloads list,”
Why do you have to run around? Do you not have a way to manage your Macs other than running around? If not, you should fix that first.
“then what happens if Apple releases something that we do need?”
Push it out with your management tools.
“Also if I do that I own the problem if it ever needs to be turned back on.”
Yes. Either _you_ administer your machines or you don’t.
I won’t be flying to China to fix this but I will have to wake the Mac Admin there and tell him how to.
Bottom line is, if Apple is going to push out an update that they know can and/or will break a process that’s running on a lot of Macs, the choice should be made by the local user, company or corporation as to if and how they are going to deploy it.
Most Mac users do not have the luxury of using the management tools you speak of that will allow them to just turn off Apple updates at any level, not to mention Adobe and all the rest.
“Bottom line is, if Apple is going to push out an update that they know can and/or will break a process that’s running on a lot of Macs…”
I understand some of the aggravation caused – but, I can’t really be upset with Apple about it. If you look at it from Apple’s point of view, there are probably a small percentage of overall computers that have the Java plug-in enabled. As an administrator, I made the choice to allow the settings to be pushed by Apple – this setting can be disabled, but I chose not to. Now I’m dealing with the ramifications. I might look ‘bad’ today, because a user may not be able to connect to a site with a java applet, however, I look good if the computer doesn’t receive the latest zero day malware because of the XProtect being enabled.
As frustrating as this is, we have to remember that as Enterprise/Corporate/Educational customers, we make up less than 10% of Apple’s business. Apple’s trying to protect the other 90% of their users, which are their core business. If Java is critical to your business processes, then disabling XProtect is the only way to guarantee that software remains functional at all times.
Greg, thanks for the ideas on managing these settings. Thankfully, Oracle uses rather compliant Apple .pkg packages for Java, so deploying their updates is much easier than some other vendors.
It would be nice if someone would put up a (github) repository and check in the xprotect plist. I think it would be easy to regularly check if the file changed and then commit the change to said repo. People could watch the repo and get notified of the change, and also be able to see the diff of the change.
There are actually two files that get updated: XProtect.plist and XProtect.meta.plist; for maximum safety you’d want to track both.
I don’t know if Apple might object to these files being posted/hosted on GitHub.
Some ideas on checking this for changes:
http://macops.ca/monitoring-apples-xprotect-meta-feed-for-changes
“They should treat this update mechanism like all other update mechanisms. I think you should turn this off on most or all of your managed machines.”
I’m curious to hear how you’re made aware of new updates when automated updaters are disabled. I get that for Apple Software Updates you can script/automate checking and downloading new updates before deploying them, but this XProtect change was so under the radar I would never have even known it happened without relying on other MacAdmins to point it out.
How are Mac admins made aware of new Apple Software Updates? One way is to run your own internal software update replica server. Some admins have scripted methods for the update sync process to notify them of new updates; personally I just check manually periodically.
For XProtect updates you could do something similar. You could write a script that runs /usr/libexec/XProtectUpdater once a day and compares the XProtect.plist and XProtect.meta.plist files against cached copies, looking for a change.
Or one could periodically check http://configuration.apple.com/configurations/macosx/xprotect/3/clientConfiguration.plist, looking for changes. This is where /usr/libexec/XProtectUpdater currently gets its updates, but that could change in the future (as could any part of the XProtect mechanism).
Ted writes:
“If Java is critical to your business processes, then disabling XProtect is the only way to guarantee that software remains functional at all times.”
Just to be clear — I don’t recommend disabling the XProtect mechanism (and I don’t even know how to do that) — just disabling the automatic updates on your managed machines. You should still review the updates and push them as much as possible.
Ted also writes:
“Greg, thanks for the ideas on managing these settings. Thankfully, Oracle uses rather compliant Apple .pkg packages for Java, so deploying their updates is much easier than some other vendors.”
I wish their package versioning followed accepted conventions, though. Every one they’ve issued so far reports its version as “1.0”. You need to look at the CFBundleVersion in the web plugin’s Info.plist to figure out the currently installed version.
Sounds like we need to get on Apple to put this in Server so we can point clients to an internal server just like Apple Software Update. And control when clients get the latest definitions.
Greg, thanks for the posts about this, although I have to respectfully disagree that disabling the auto-update mechanism for Xprotect should be done in organizations with managed machines. Do you disable the automatic update mechanism for your anti-virus software? Do you manually test every definition update and push each one out through Munki? I’d assume not. Xprotect (clearly) isn’t serving the same type of updates as Apple software update. It’s a malware prevention/blocking (and in some cases, removal) system. I won’t argue that Xprotect’s disabling of Java plugins will almost certainly have a larger impact across organizations than say something like a Sophos definition update, but nonetheless, the intent is still to protect systems. Xprotect and anti-virus software together are meant to serve complimentary roles. These Java plugins are being disabled because serious known exploits are being used in the wild. For a company that cannot function without version xyx of the Java plugin, does it make sense to make changes so that it can continue to operate effectively? Sure. But I doubt most organizations rely that heavily on a single plugin. Also, how many different types of updaters should we as admins be responsible for managing? There are already too many. For most admins, I don’t think it’d be a responsible decision to add Xprotect to the list.
– Mike
I agree somewhat, but taking that argument, if an anti virus update does break something in production (which happened all the time on the Windows side years ago), then you can bet that I’m disabling auto update from the management console for a period of time until I can be sure that updates won’t cause the issue again. I’m with Greg on XProtect using that same reasoning.
[…] Trials and Tribulations of an OS X Administrator « More thoughts on XProtect Updater […]
[…] If you don’t want to be surprised by this sort of thing and scramble to address it, might I point you here? […]
Do you think that it is “safe” to disable Xprotect updater completely?
I am using Munki with a nopkg-script which sets currently installed Java and Flash versions on the client as “trusted” by modifying the xprotect meta-file.
That way I have some additional time to distribute Java and Flash updates without end users suddenly losing Java/Flash functionality.
And malware protection by Xprotect is still partially valid as Xprotect has the latest information except for Java and Flash.
If Xprotect updater is disabled then admin should find a way to update Xprotect-metafile if admin chooses to have it up-to-date?
Now that I think of this I should probably make this as a LaunchDaemon so it will run without connection to Munki server…