Apple (FINALLY) releases OSX.Flashback removal tool....

[donmontalvo]

http://support.apple.com/kb/HT5242

[mm2270]

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.

[donmontalvo]

I suppose we can run an EA that would query softwareupdate for the patch, and if it's available say YES.

We need a way for the analysts to pull reports on which Macs have not received these new patches.

Don

[mm2270]

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.

[bbass]

Going to crosspost a little here...

https://jamfnation.jamfsoftware.com/discussion.html?id=4206

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.

[mm2270]

Thanks! That's a good method to track this, Better than looking at the build number probably.
I'll give that a try too.

[jhbush]

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]

i just posted a blog entry about the removal tool portion.

does that seem about right?

http://rockpapergoat.com/blog/2012/04/13/osx-java-security-update/

[mm2270]

@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.