eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Id seen it myself recently, but Symantecs Security Response team has officially noticed that attacks on Java are on the rise.
We were all probably a little too naive back in the mid-90s when Java came out promising, among other exaggerated claims, immunity from security problems. There were always some Java security issues, but they werent realistic threats, just proofs of concept that nobody would bother to implement.
Most of the higher-profile problems seem to be more in the interface between Java and the outside world. Recall earlier this year, when there were a series of high-profile security flaws in the QuickTime Java interface. There have also been a series of vulnerabilities in recent months in Java Web Start. The news in these cases was about vulnerabilities and not about exploits.
Some of the exploits are purely in the Java end of things, and they turn out to be the same sorts of software operations that are prone to vulnerability in non-VM software. Consider the recent vulnerability in Javas image parsing code. The parsing of data coming out of files seems to be a never-ending source of security issues in all platforms. Many such problems in less-famous applications go largely unpublicized, even when they are properly reported and fixed by the vendor.
And Java is a relatively standard part of the Internet landscape and malware authors seem to be getting around to it. The reason Symantec wrote their blog was because these exploits are starting to show up on their massive world-wide honeypot network. I have seen other public reports of malicious Java code, such as this one from the ISC.
It could be that were just getting started with Java as an exploit platform. Symantec notes, for example, that Javas heap management makes it possible for it to be used to develop heap spraying code. (See this other Symantec blog and the links in it for more on heap spraying and heap feng shui, now-popular techniques for throwing code up against the wall to see what sticks.) If these could be made largely reliable—even if it only worked 50 percent of the time that would be more than enough—Java is on a steep slide into trouble. Its not clear to me whether a rewrite of Javas heap management to address the problem would cause compatibility problems for actual Java code.
Symantecs advice for dealing with Java security issues is disturbingly mundane: keep your Java implementation up to date, use an IDS/IPS (intrusion detection system/ intrusion prevention system) and keep the signatures up to date, dont browse unsecure Web sites, etc. Just like with non-Java products.
But, werent things supposed to be different?
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer