It is indeed ironic. It would almost be funny. except that we have a number of internal websites users need to access that require a Java web plugin to work. We're waiting for the calls and tickets to start flooding in. Oy!
I understand Apple is trying to be more proactive in protecting Mac users, which is admirable, but I think they took this one a bit too far.
I will be sure to mention this to our Apple rep next time we speak to him. Apple needs to hear from us about how this action was unacceptable without at least a 24 hour warning that it was coming.

I will be sure to mention this to our Apple rep next time we speak to him.

Pffft mine got a nasty gram hours ago.

Taking it too far, as you say, only forces people to completely disable the protection, making the move even worse on their part. I would stand by and be happy if they gave an error message and the default was to block the plugin, but to do it silently in the background is just wring.

Wow, Apple wants to control Java in OS X but they don't work with Oracle to prevent these issues.

This is one of those $hit or get off the pot moments for Apple. :(

Nothing's reached us yet, but I'm sure there'll be some escalations soon.

Don

Jared, are you just killing the file, or are you then dropping in a hand-edited one? Just thinking about how I'm going to get this to off-site people I can't drop a file to.

I put a ticket in with Apple. They responded with the unload command Jared posted above with a big security risk disclaimer with it.

It's a shame the safe download list check box doesn't allow admins to select which products they can disable, or disable versus notify, etc.

Apple should be popping up a notice when they do this. It just causes client confusion and then more work for support people. I sat on an ER and now I'm going to file it. This process sucks.

We had contemplated doing the same as Jared and disabling the XProtect function altogether, but we won't be going in that direction. Our concern is that we have some clients that go off the network for days or weeks at a time. We don't have an externally facing JSS yet, and so some clients may stay with XProtect disabled for longer than we feel comfortable with. It would just leave those people a bit exposed. As much as this sucks, I'd rather err on the side of overprotecting for now and simply write in an older plug-in value back into the plist each day with an ongoing policy than turn it off completely. We're not willing to take that risk. But that's just us.

May be of help to some:

http://managingosx.wordpress.com/2013/01/31/disabled-java-plugins-xprotect-updater/

Others may need to customize it. (Hint: edit the postflight script)

I've got a post up now about this issue: http://derflounder.wordpress.com/2013/01/31/java-blocked-in-safari-on-10-6-x-10-8-x/ It looks like the workaround for now is Firefox.

And someday soon even this won't be an option:
http://www.pcworld.com/article/2026686/mozilla-plans-to-automatically-block-nearly-all-firefox-plug-ins.html

As long as it's only the web plugin and not the runtime, i'm in the minority of not caring. Java is an optional install for us.

Firefox is not planning on blocking all plug-ins. It's called click to play https://blog.mozilla.org/security/2013/01/29/putting-users-in-control-of-plugins/ If you want your Java plug-in to run in firefox click the box to allow. I am all for that as opposed to what Apple is doing.

@Nick_Gooch, thanks for the clarification. The article I linked to is misleading in how its worded, but after reading it again I see what you're referring to. The article has statements like "barring all browser plug-ins" so I though Mozilla was changing even how the Click to Play function worked, but you're right. Doesn't seem to be the case.

I read an article that was similarly worded. The one I posted is from mozilla so hopefully that will help clear up some confusion with that.

Another option to fix the Java issue would be to edit the plist for the java applet to report as 1.7.11.22

/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Enabled.plist

This would make it so you didn't need to turn off XProtect. Might cause the java auto updater not to update in the future though.

Alternatively, take Jared's first line (unloading and disabling the daemon) and instead of deleting the plist, replace it with a modified version.

Anyone else seeing an increase in network traffic on port 80 after the XProtect file was updated? Our Security and Network guys have noticed that the Macs are suddenly chatting out to the Internet since this morning.

** Never mind, mystery solved, just a coincidence. **

Anyone else having issues with unloading xprotect? I'm using a script similar to Jared's and about half of the computer logs show: "launchctl: Error unloading: com.apple.xprotectupdater"

Anyone else having issues with unloading xprotect? I'm using a script similar to Jared's and about half of the computer logs show: "launchctl: Error unloading: com.apple.xprotectupdater"

I've been seeing this as well. On my machines where it fails, a user happens to be logged in. When no one is logged on, it's been working fine for me.

Looks like I'm mostly getting this error because the computer already had the launch item disabled. The following code seems to resolve that:

#Disable XProtect
/bin/launchctl list | grep "com.apple.xprotectupdater"
if [[ $? = 0 ]];then
    /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.xprotectupdater.plist
fi

Unloaded xprotectupdater and renamed XProtect.meta.plist.

Now seeing in Mail, messages with attachments (PNG, JPG, ZIP) showing "Blocked Plug-In" instead of showing the images.

Putting XProtect.meta.plist back, it showed the images.

As a compromise, I edited that file and put it back a level so the Java will work on this machine.

The updater daemon remains disabled.

Outlook does not appear to be effected.

Hi, This is likely related to the CERTIFICATE for that version of Java having expired Today.

Items that check that certificate, will correctly fail, since the code is now marked as non-valid, from a security standpoint.

Oops - I should clarify: I am talking about Java Vn 1.6

Apparently Apple blocked Java 7 vn 11 on 31-st Jan 2013, due to a security issue…
( www.macnews.com/2013/01/31/apple-blocks-java-7-update-11-mac-os-x )

Which I think might mean no usable version of java at the moment ??
-- Until a new Oracle release is made with a bug fix...

http://www.oracle.com/technetwork/java/mac-138071.html - must be out of date. Says that Apple is doing the PlugIn

The current Java downloads are available from
http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1880261.html

Mac OS X x64 50.31 MB jre-7u11-macosx-x64.dmg
Mac OS X x64 46.65 MB jre-7u11-macosx-x64.tar.gz

But if Vn 11 has just been blocked… Then they won't work…
-- Personally I have not tried to use them recently.

Instead of disabling XProtect, we are using another approach to get Java 6 back: We fake the version string inside the JavaVM plugin to be of acceptable value. If Apple ever should update the JavaVM, those changes will be automatically overwritten, so it should be safe to "fire and forget".

Benefit: This will allow XProtect to still do it's work on other malicious software, but prevent it from stopping Java.

This is the script we use:

#!/bin/bash

####################################################################################################
#
#       Copyright (c) 2013, Christoph von Gabler-Sahm (christoph.gabler-sahm@computacenter.com).
#       All rights reserved.
#
####################################################################################################
#
# ABOUT THIS PROGRAM
#
# NAME
#   HSD_FixJavaXProtectBlock
#
# SYNOPSIS
#   HSD_FixJavaXProtectBlock targetDrive computerName userName
#
# DESCRIPTION
#  
#   Avoids Java to be disabled by XProtect by faking a version number which is higher than the
#   blocked version. This avoids having to disable XProtect completely.
#
####################################################################################################

if [[ "${1}" == ""  ]]; then
    TARGET_VOLUME="/"
else
    TARGET_VOLUME="${1}"
fi

# fixes JAVA by faking an acceptable version number

APPLE_JAVA_PLUGIN_PLIST="${TARGET_VOLUME}/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Info.plist"
APPLE_JAVA_VERSION_BLOCKED="1.6.0_37-b06-434"
APPLE_JAVA_VERSION_TO_FAKE="1.6.0_37-b06-435-faked-for-XProtect"

APPLE_JAVA_VERSION_CURRENT=$(/usr/libexec/PlistBuddy -c "Print :JavaVM:JVMVersion" "${APPLE_JAVA_PLUGIN_PLIST}")


if [[ "${APPLE_JAVA_VERSION_CURRENT}" == "${APPLE_JAVA_VERSION_BLOCKED}" ]]; then
    # change version number to an acceptable value:
    echo "Changing Apple Java Version number to ${APPLE_JAVA_VERSION_TO_FAKE}."
    /usr/libexec/PlistBuddy -c "Set :JavaVM:JVMVersion ${APPLE_JAVA_VERSION_TO_FAKE}" "${APPLE_JAVA_PLUGIN_PLIST}"
else
    echo "Installed Apple Java Version ${APPLE_JAVA_VERSION_CURRENT} != ${APPLE_JAVA_VERSION_BLOCKED}. Doing nothing."
fi

@cvgs, I'm liking this approach. We haven't made a decision yet on how to circumvent this push from Apple (hoping to come to a resolution today), but the approach of touching or disabling anything related to XProtect is not winning any votes here.

I adapted your process to test this with the Java 7 plug-in and it seems to work nicely. Here is a PlistBuddy command to "fake" the Java 7 plug-in to report its running version 1.7.11.22, so XProtect leaves it alone.

sudo /usr/libexec/PlistBuddy -c "Set :CFBundleVersion 1.7.11.22" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist