Just an FYI for everyone on this. From what I can see, this update is actually the same version of Java as released on 4/3/12, but includes functions to detect and remove Flashback as noted by Apple's kb article. Because the version number for Java for both updates is identical (1.6.0_31) if you have any scripts that try to detect outdated Java on your clients by version, it won't catch any systems already running Java version 1.6.0_31 unless you modify the script to capture the build number, which does differ.
Old Build: b04-414-11M3626 New Build: b04-415-11M3635
This is somewhat minor though since any system already running 1.6.0_31 should already be protected from the malware. It just wouldn't have removed any existing infection after the install the way this new build supposedly will.
Yeah, well if you have the new Java opened up on your SUS and you're collecting software updates during inventory, it should be a simple matter of making a Smart Computer Group based on "Available SWUs" has "JavaForOSX-1.0" or "Available SWUs" has "JavaForMacOSX10.6-8.0"
On the other hand, in our case we don't open updates on our SUS until they are fully tested, mostly because many users are admins on their boxes (I know, I know)
So I will likely run an EA called something like "New Java installed" that will pull the build number and depending on match, enter a result of YES or NO. Its less processing overhead for the clients than running a 'softwareupdate -l', and it gets around the issue of opening the update up on our SUS. (We could always query Apple's servers directly to get a result as well)
Something like this-
#!/bin/sh
JavaBuild=`java -version 2>&1 | awk '/Run/{print $6}' | awk '{print substr ($1,10,15)}'`
if [ $JavaBuild == "b04-415-11M3635" ]; then
echo "<result>"YES"</result>"
else
echo "<result>"NO"</result>"
fi
The above may need to be expanded on to account for any systems that don't have Java installed so I don't end up with false results though.
We are tracking Java updates via the CFBundleVersion which seems to be more straightforward than using 'java -version'. Yesterday's updates have the following values.
10.7: 14.2.2 10.6: 13.7.2
The previous versions were 14.2.1 and 13.7.0, respectively.
So we create a smart group based on the EA that documents what version machines are currently running. If it isn't the most current, then we push out the package via a policy.
In a semi-related note if you are using the auto-check box script for java this latest version unchecked the box. This may cause some confusion for juniper vpn users. It also disables the Java plugin after 35 days of inactivity according to the release notes.
@rockpapergoat - good sleuthing. I suspected this update didn't do much other than a removal process 'Course I didn't suspect it just deletes itself when it's done! Seems pretty bizarre.
I wish Apple would build some protection against Flashback into the built in XProtect on OS. X. That would make more sense than a one off clumsy removal tool. But maybe the way this Flashback malware works that would be hard for them to do. Not really sure.