Why You Can't Dump Java (Even Though You Want To)
It's easy for some of us to say, "Hey, let's get rid of Java." But I bet the businesses that require and need it are equal in number to those that are able to abandon it.
Java flavor of the month
I'm not someone who jumps on on the "throw this program out" bandwagon, for a few reasons. If we got rid of Java, the same problem (computers exploited using popular software) would come back to haunt us in a different form. Five years ago, most Internet exploits came through Internet Explorer, which is no longer true. A year or so ago, it was Abobe Acrobat PDF exploits or Adobe Flash Player exploits. This time it's Java.
Another bigger lesson I hope readers understand: Security sandboxes don't work when they become popular (see the Grimes hacking popularity corollary). Java was created in 1995 by James Gosling and Sun Microsystems. It was built from the ground up with security as a pillar. It's integral to the language and its runtime environment. Very smart people contemplated the problems that could occur and created offsetting security solutions.
For all their good intentions, it didn't work. Java has always been among the most successfully exploited software from the beginning. It turns out the security sandbox -- all security sandboxes, for that matter -- aren't so safe once hackers turn their attention to them.
Many vendors send me their security sandbox products for review, and I always turn them down. Why? While they temporarily increase security, none would withstand the passage of time if they became popular. How do I know? Because all popular security sandboxes made since the beginning of computers have fallen. Show me one popular security sandbox that didn't fall.
The real failure
A good recent example is the Google Chrome browser's security sandbox. Google Chrome and its security sandbox offer a great design and idea. Their framework should make them the most secure browser, yet the Chrome browser has suffered hundreds of found security exploits since it came out in September 2008. It has more found exploits than its competitors, and more often than not, those exploits lead to complete system compromise.
I'm not trying to pick on Google Chrome. Whatever becomes popular gets exploited most. Google Chrome, even with its hundreds of known vulnerabilities, does not get exploited as much as Internet Explorer or Firefox.
The lesson is that an application using a security sandbox does not equal better security. Don't get me wrong, sandboxes help -- just like antimalware scanners help. They reduce security risk, but they are in no way a panacea.
The bottom line is that we aren't addressing the real problems. It isn't a security bug here and there in a particular piece of software; that's a problem we'll never get rid of. Instead, we allow almost all cyber criminals to get away with their Internet crime without any penalty. They almost never get caught and punished. Until we solve the problem of accountability, we will never get rid of the underlying problem.
Getting rid of Java certainly won't fix that.
This story, "Why you can't dump Java (even though you want to)," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
Why You Can't Dump Java (Even Though...