Once Again: Java Vulnerability
In light of the recent set of vulnerabilities found within the Java SE 7 browser plugin, I've read stories and heard from people who are completely uninstalling Java from their computers. In my opinion, this is an over-reaction to an issue that affects only one thing: the Java plugin for the browser. This is used only to run Java Applets or Java WebStart to launch applications via the browser. Considering there are three other types of Java applications that are unaffected (Java Embedded applications, Java SE desktop applications, and Java EE web-based or enterprise applications), this is only a small portion of the Java world. On top of that, there honestly aren't many Java applets in use these days, so the need to use the Java plugin is minimal.
- Top Six Things to Consider with an Identity as a Service Solution
- Infographic: Challenges in Managing a Hybrid Cloud
- IT and LOB Win When Your Business Adopts Flexible Social Cloud Collaboration Tools
- How to Protect Your Content and Improve Security with Cloud Client Computing and Thin/Zero Clients
To be clear, these specific vulnerabilities don't affect real-world server-side deployments (Java EE), or even Java SE desktop applications such as Eclipse or Netbeans, JavaFX, Swing, and so on. There really is no need to uninstall the JDK or JRE. Users need only disable the Java plugin in their browser.
One point I've been trying to make to friends and colleagues, beginning with the previous rash of vulnerabilities (see my previous blog), is that this is only an issue if the user browses to a malicious web site. Java or no Java, pointing your browser to a malicious web site is dangerous and leaves you vulnerable either way. You could raise the point that even a legitimate site can get hacked, and a Java zero-day attack launched from it. However, I would add that if a site got hacked, you're still open to vulnerability with or without the Java plugin enabled.
Oracle's Java SE 7 update 11, released to address this issue, included a description of the issue and resolution. In summary, the change included a control panel setting to block unsigned Java applets from running automatically. I've heard that only one of the two vulnerabilities discovered this week has really been patched, and I've also just read that an even newer vulnerability has been found. If this is true, it could spark a big change for the Java browser plugin design.
Either way, this doesn't mean that Java is an insecure language or platform, or that web sites built on Java EE are any less secure than other platforms. Unfortunately, perception often beats reality, and Java is getting a big black eye from this one. Hopefully Oracle can do more than just release updates to patch the vulnerabilities. They need to launch a campaign that explains the differences, as well as take steps to stop these vulnerabilities more effectively.