Oracle Java, easily the most attacked and successfully exploited browser plugin, is on my radar again after finding new ways to fail at security.
The first sign of trouble recently was posted on Jerry Jongerius’s site, Duckware. He described the embarrassingly broken code signing implementation in the Java Runtime Environment (JRE).
The purpose of code signing is to cryptographically ensure that you can identify who created a program and that it hasn’t been tampered with by any third parties.
For example, Oracle offers a test applet (applets are Java programs that run in your browser) to determine whether your version of Java is update to date.
When you download the applet with Java, you are prompted to run the applet with a warning that Java applets can be dangerous, the name of the applet, the publisher and the URL serving it to you.
While the name can be anything, it is usually there to remind you of why you want to run this Java program.
The publisher should provide a clue as to whether it is from the expected source and the URL verifies that it is coming from the expected site.
What Jerry discovered is that you can forge both the application name and the URL to be anything you want. In essence, they’re doing it wrong.
Even worse, signed Java applets run with full privileges, largely removing all the security advantages of the language’s much touted sandboxing technology.
Now Oracle is rolling out another misguided attempt at shoring up Java security.
Because they intend on discontinuing one of the most popular versions of Java (1.6) in April 2014 (a bad month for Java 1.6 Windows XP users) they decided to build a bit of a bridge for enterprise users called “Deployment Rule Sets”.
Oracle’s concept is that enterprises who have a certificate for signing Java applets will be able to sign a policy for their outdated applets that allows them to continue to operate insecurely, even if the device is running a more modern version of Java that prohibits these behaviors.
Wow. What a dream for attackers who deliver malicious applets as a means of delivering malware to your PC/Mac.
It’s a complicated way to disable security warnings that in no way deters cybercriminals, but is too complicated for most organizations to manage and deploy.
This feature of course offers no security benefits at all to normal Java users and arguably very little for corporate customers.
Worse yet, everyone’s Java installation (if you are running a recent enough version) will be vulnerable to attackers exploiting the “feature.”
All you need to do is digitally sign a package containing a policy to disable most security restrictions.
These signatures aren’t just valid for inside your company; if they are included in a Java applet they can apply anywhere.
The only possible penalty for deploying one of these policies in the wild to do harm is the revocation of your signing certificate.
If you’re a crook and have either stolen a certificate from an infected PC or have convinced a certificate authority you might want to publish legitimate apps you’ve got nothing to lose.
This addition to the crazy maze of security options present in varying versions of Java is enough to make your head spin.
If we have learned anything over the years, complexity is the enemy of security. We must design security technologies that just “do the right thing” and don’t require byzantine decision making trees on behalf of the user.
Unfortunately, Oracle has chosen a different path. I stand by my advice to disable Java whenever possible. If you haven’t already, read our post on how to disable Java in your browser.
If you have any remaining doubts about Oracle’s commitment to security, consider how it is still trying to install the Ask toolbar when you download updates to Java.
Apparently $37.2 billion in revenue isn’t enough to not clutter your browser’s toolbar and increase the attack surface of your browser in the process.