Posted on 01-31-2013 05:41 AM
I am getting the error:
The version of “Java” on your system does not include the latest security updates and has been blocked. To continue using “Java”, download an updated version from Oracle’s website.
I am running 1.7u11. I found two posts earlier today on Apple's forums of people experiencing the same issue beginning this morning.
Are any of you guys seeing this?
Solved! Go to Solution.
Posted on 01-31-2013 05:58 AM
Yes, all of our Macs have had this issue. We have Java 6 on 10.6 and Java 7 on 10.7/10.8. On users' Macs that needed urgent access to Java in a web browser I pushed out a modified XProtect.meta.plist file which is located in /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/
I changed the JavaWebComponentVersionMinimum key to 1.6.0_37_b06-434 and the MinimumPlugInBundleVersion key to 1.7.11.21
After you deploy the updated file to the Mac the user just needs to restart their browser and Java will be enabled again.
Posted on 01-31-2013 01:30 PM
Alternatively, take Jared's first line (unloading and disabling the daemon) and instead of deleting the plist, replace it with a modified version.
Posted on 01-31-2013 01:41 PM
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. **
Posted on 01-31-2013 01:59 PM
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"
Posted on 01-31-2013 02:13 PM
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.
Posted on 01-31-2013 03:22 PM
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
Posted on 01-31-2013 08:13 PM
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.
Posted on 02-01-2013 02:24 AM
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.
Posted on 02-01-2013 02:25 AM
Oops - I should clarify: I am talking about Java Vn 1.6
Posted on 02-01-2013 02:40 AM
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.
Posted on 02-01-2013 06:33 AM
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
Posted on 02-01-2013 07:42 AM
@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
Posted on 02-01-2013 08:55 AM
Help!
I cannot get the Java plugin to work on some of our 10.6 machines. I get a missing-plugin this is for Tune In for Reading and the little kiddos cannot use the application.
Posted on 02-01-2013 09:54 AM
Some food for thought while Googling:
http://osdir.com/ml/general/2013-02/msg00308.html
Posted on 02-01-2013 12:01 PM
Hey, heads up everyone- Java 7 Update 13 is now available from Oracle's downloads page:
http://www.java.com/en/download/mac_download.jsp?locale=en
So, looks like Oracle was either working on this and release was imminent, or Apple's steps yesterday accelerated their release schedule for this. Hopefully the former.
I do wish that Apple could have just stated that a new release was coming if they knew that. Its looking more and more like Apple jumped the gun on this. Maybe update 13 was supposed to be released yesterday.
Posted on 02-01-2013 12:50 PM
So. Much. Dislike for both companies right now...
Oy.
Posted on 02-04-2013 12:20 PM
Per Oracle's release notes for Java 7 update 13, the update was originally scheduled for release on February 19, 2013. Why would Oracle schedule critical update releases...if they're critical, don't hold the updates back! We are capable of making our own deployment schedules. Apple's action, while less than ideal, certainly pushed Oracle to act in a more timely manner.
Posted on 02-04-2013 12:21 PM
Also FYI, Java for Mac OS X 10.6 Update 12 is also out, for Snow Leopard users.