More thoughts on XProtect Updater

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.

Advertisements
More thoughts on XProtect Updater

Disabled Java Plugins, XProtect Updater

JavaToday Apple updated the XProtect.meta.plist file, which, among other things, causes XProtect to disable Java Plugins that don’t meet a minimum version.

The net effect was to disable the Java 6 plugin on all browsers, as well as Java 7 plugins older than 1.7.11.22.

If you need to continue to use the Java 6 plugin in your organization, you can revert the changes and disable the mechanism that updates the XProtect.meta.plist by installing this package:

https://dl.dropbox.com/u/8119814/DisableXProtectUpdater.pkg.zip

This is a payload-free package that runs this script as a postflight:

#!/bin/sh

# don't check JavaWebComponentVersionMinimum
XPROTECT_META_PLIST="$3/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist"
/usr/libexec/PlistBuddy -c "Delete :JavaWebComponentVersionMinimum" "$XPROTECT_META_PLIST"

# disable the xprotectupdater job
LAUNCHD_JOB_PLIST="$3/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist"
/bin/launchctl unload -w "$LAUNCHD_JOB_PLIST"

I won’t tell you this is a smart thing to install; there are many reasons to leave things as they are. Apple disabled these plugins to protect from known exploits. By re-enabling them, you are opening up your managed machines to these exploits.

But if your org needs the Java 6 Web Plugin, this should get you running again. You should re-enable the XProtect updater as soon as you are able, though:

sudo /bin/launchctl load -w /System/Library/LaunchDaemons/com.apple.xprotectupdater.plist

NOTE: if you need to re-enable an older version of the Oracle Java 1.7 Plugin, you’ll need to edit the postflight script and add something like:

/usr/libexec/PlistBuddy -c "Set :PlugInBlacklist:10:com.oracle.java.JavaAppletPlugin:MinimumPlugInBundleVersion 1.7.10.19" "$XPROTECT_META_PLIST"

(Sadly, WordPress changes a colon followed by a P into a emoticon, even in pre-formatted text. Not helping…)

This sets the MinimumPlugInBundleVersion for the Oracle Java Web Plugin back to the value it was with the 10 Jan 2013 version of the XProtect.meta.plist. Again, if you do this, you are choosing to expose your machines to a known Java Web Plugin exploit. Do so at your own risk.

(Update 01 Feb 21013)
If you need to run the Oracle Java 1.7 Plugin (or are already running it and it’s been disabled) the best fix is to update the Java install. As of this writing, Java 7 Release 13 for OS X is available here. This installs a web plugin with BundleVersion 1.7.13.20.

(Update 02 Feb 2103)
Apple has released a Java 6 update for Snow Leopard. Installing this update will restore Java 6 web plugin functionality under Mac OS 10.6. This won’t help if you need to use the Java 6 web plugin under OS X 10.7 or later.

Disabled Java Plugins, XProtect Updater

Fix for Adobe CS6 activation issue

PSCS6
Adobe has posted some information and a fix for the recent issue with Adobe Photoshop CS6 registration/activations:

http://blogs.adobe.com/oobe/2013/01/32767-days-left-but-whos-counting.html

This issue appears to have been triggered by the Photoshop CS6 13.0.2 and/or 13.0.3 updates. The official recommendation on a fix is to update Photoshop CS6 to 13.0.4, then use the APTEE tool to remove and reapply serialization. See the above post for more details.

The APTEE tool is not exactly easy to use to deploy this fix in an enterprise environment; you need to install it on all your machines and also run a script (which you must write, test, and debug) on all your machines to perform the unserialization/reserialization.

Later today I will post a tool to help you create a standard Apple package to perform these steps. If you have some way to distribute and install Apple packages on your machines, you’ll be able to do the unserialization/reserialization by installing a package.

Check back later!

Fix for Adobe CS6 activation issue

Adobe CS6 Serialization fun

Recently (starting some time after the first of the year), we’ve started having users call and tell us that their formerly working install of Adobe Photoshop CS6 was now asking for a sign-in:

AdobeIDrequired

We could not figure out why this was happening. An uninstall and reinstall of our AAMEE3-generated installation package seemed to get things working. But then the same users would call back the next day with the same issue.

Continue reading “Adobe CS6 Serialization fun”

Adobe CS6 Serialization fun

MacTech Conference 2012

MacTech Conference 2012 is a little over two weeks away! If you haven’t registered yet, get $400 off the regular registration price by following this link: http://www.mactech.com/events/IKnowASpeaker

I’ll be presenting again this year. More exciting, on Wednesday evening, October 17th, MacTech Conference attendees will be guests at a special event at Walt Disney Animation Studios. Not only will they get a behind-the-scenes look at the Animation Studios and talk with Disney technologists and artists, but also have a rare look at how Walt Disney Animation Studios uses advanced technology to create their animated films.

I look forward to seeing you there!

MacTech Conference 2012

Flashpoint and Counterpoint

TGB is back with more interesting comments.

Thanks for your comments, TGB! Let me respond to a few:

Vendor-supplied DMGs are standard for distribution, however they are not standard for deployment.

You say that only because your deployment software doesn’t support deploying  directly from a drag-n-drop disk image. I think this is a case where we should bow to reality — since a lot of software is distributed this way, your software deployment system should make it easy to deploy software distributed in this format.

Default settings are part of deployment. They simply are.

Most consumers seem to be able to purchase, install and use third-party software with the default settings as chosen by the vendor. We find that also to be the case in our environment — we don’t have to customize settings very often. But when we do, we have lots of available tools to do so. Not having to (re)package the software itself gives us more time to spend on adding value for our organization.

I’m completely comfortable packaging Flash by hand.

That’s great. So am I. But not every admin is, judging by all the packaging questions I’ve seen. More importantly, what’s the value of hundreds or thousands of admins repeating the same task, but perhaps doing it slightly differently? Let’s have the vendor do that work.

I don’t work in a rigid corporate environment.

Neither do I!

Flashpoint and Counterpoint

Flash Dance

In comments on my previous post here, TGB makes some interesting points:

While you’re not wrong that Flash Player deployment isn’t ideal, and it should be as easy as dragging and dropping a pkg, I don’t see how the repackaging route is any more of a waste of time than any other product. Adium, Mactracker, Firefox, Chrome and a whole bucket of other apps all require packaging to be deployed. Sure, they might auto-update, but you have to get an initial version out there, not to mention getting your preferred default settings out too.

Most, if not all the items mentioned (Adium, Mactracker, Firefox, and Chrome) are distributed as “drag-n-drop” disk images where the user is expected to drag the application to the /Applications folder. I’d argue that is an industry standard deployment method. The software deployment system I use (Munki) can install items like this without the need to package them. If your software deployment mechanism does not, perhaps you should be requesting that feature from your vendor, since this is a very common distribution format, and code-wise, requires  little effort to support. When a new version of Firefox or Chrome comes out, I just download the disk image and directly import it into Munki — no packaging needed.

Adobe Flayer Player cannot be distributed as a drag-n-drop application disk image — it’s not an application. So the “correct” distribution format for this software is the Apple package format.

Preferred default settings is a completely different issue. As long as vendors use Apple’s preference file format, this is solved with MCX or Lion/Mountain Lion profiles.

TGB also writes:

Not to mention, with any of these products, testing them (yes?) is more time and effort-intensive than any actual packaging. 3/4 of deployment and integration is non-technical work. A couple of minutes difference doesn’t really matter in the scheme of QA, UAT and change management process (or are others just not doing that?).

Flash is not needed by any business-critical application where I work, yet our users demand (or at least expect) it and Apple and Mozilla demand it stay up-to-date, or they will disable the plug-in. So for us at least, testing is quite minimal for Flash. If it installs and can display some Flash content, it’s good.

But yes, I do understand and sympathize with admins that must test each release of Flash with business-critical applications — and Adobe’s distribution format is not the key issue here; frequency of releases is. I’d argue that this is an impetus to reduce or eliminate your internal dependency on Flash.

Where I disagree with TGB: Adobe’s non-standard distribution adds more than a “couple of minutes” to preparing a new release of Flash for enterprise distribution. If we could be sure that Adobe will never change anything about their installer and updater, we could just figure out a process and repeat it for each new release. But Adobe can and has changed things, so for each release we must also test that our packaging/repackaging/custom deployment steps actually end up with the desired results. This is usually not a huge deal, but also cannot be ignored. But more importantly, theirs is a one-off solution. If we have to keep track of and test different deployment solutions for each vendor and product, we end up wasting a lot of time and effort, and making a lot of mistakes. Where would it end? Unique software deployment methods for each vendor? (Oh that there was only ONE unique deployment method for Adobe software!)

No, a line must be drawn. Here. No farther.

Flash Dance