By Nash Pherson -
Now that we’re all well rested after MMS 2013, it’s time to get back to work. Oracle was nice enough to announce a Java critical security update that fixes a mere 42 bugs today to get us back in shape. The highest CVSS Base Score of these vulnerabilities is a solid 10.0 on the ‘patch now or disconnect the internet’ scale. These vulnerabilities “may be exploited over a network without the need for a username and password.”
Read the Oracle Java SE Critical Patch Update Announcement
But Java 7 Update 21 update is different than the last dozen times you have diligently secured your systems and protected your organization. Most Java updates are very easy to test and deploy, and they can typically done in the background without even mentioning anything to your end users. However, Update 21 introduces some in-your-face changes that your end users will notice, and these changes should have IT admins considering putting some end-user communication together.
Java 7 Update 21 introduces a series of new security prompts based on the trust level of the code signing certificate. Code signed by a trusted certificate will prompt your for “Do you want to run this application” when launching. Code that is not signed by a trusted certificate will give a security warning dialog box that states “Running this application may be a security risk”. The user will have to check a box stating they accept the risk.
Why add the extra hurdle before executing unsigned/untrusted code? Because you are about to execute unsigned/untrusted code, that’s why. Oracle is starting to understand how bad it is being at the top of the hit list for virus writers. Steps like this help mitigate the risk of their highly vulnerable code base and are worth the annoyance.
For the full scoop on the security prompts, see this article:
Be sure to go through and test the Java apps your organization uses. Large organizations will likely have a couple apps that will now prompt before running. When you start running into unsigned/insecure apps, don’t just blindly flag them as allowed. Instead, push the developers to follow Oracle’s security criteria and sign the code using a trusted certificate. You do not want to train your users to just hit ‘allow’ every time they see a warning like this… If it is supposed to be something that is trusted, then get the code signed.
Send these links to your developers who need help figuring out the whole “trust” thing:
I’m reminded of how thankful I am for tools like Secunia’s CSI plugin for ConfigMgr. CSI frees up a ConfigMgr Admin’s time so they can actually do good testing and communication rather than hand-writing an upgrade package. And since it covers almost 25,000 products, that’s a lot of freed up time. See Kent Agerlund’s quick walk-through for a good look at Secunia CSI and ConfigMgr.
As you go through and try to identify all your Java apps, you may end up realizing that not everyone has a business need for Java to be installed. Consider saving yourself a lot of effort (and the organization a lot of risk) and uninstall Java where it really is not needed. I recently worked with a very large K-12 school district that was able to remove Java from all but a handful of machines.
Watch for a post in the next few days discussing some great new security research that was just published about 3rd party application vulnerabilities… It’ll get you fired up to get Java up to date even if requires you to communicate with you end users.
I hope that helps!