The runtime isn't written in a managed language, and that's where most of the vulnerabilities happen, right? The holes aren't in application code, but in _running arbitrary code_, which the JVM fails to do safely.
The surface area exposed is larger, because you're allowing the browser to download and run arbitrary programs, something you don't do with unmanaged languages very much.
Edit: Also, just consider how much worse it'd be if Java apps were re-written in a language that allows buffer overflows. Enterprises already cannot get security right; even generating SQL queries results in problems. No way would those teams deal with yet another layer of security issues. Hell, I've dealt with commercial teams writing in C++ thinking a buffer overflow has "something to do with network rate limiting."
> "The runtime isn't written in a managed language, and that's where most of the vulnerabilities happen, right?"
At least some of those Java vulnerabilities are logic errors in the sandboxing/securitymanager parts that are supposed to prevent applets from accessing privileged APIs, and those checks are usually implemented inside the actual java.* standard library classes, in the Java language.
The problem mostly isn't the runtime itself, but instead the various 3rd party modules (all of which are written in late-90's-era C/C++) that get hooked up to the JVM. For instance, the Quicktime API for Java exposed scalar integers, intended to be "opaque", but in fact raw memory locations.
The JVM is good. The Java Applet Plugin, on the other hand, is a problem.
Well, sure. But I think that's maybe missing my point -- a managed runtime needs "holes" in it to do its job, which exposes the security problems of the rest of the system via inevitably leaky abstractions. The point was that the managed runtime does nothing to address this, it has to drill down to a C API at some point (or deeper, consider a similar hole in a shader compiler or video codec accelerator).
And contrast with alternative affirmative/MAC-based sandboxing schemes like Chrome's NaCl, or OS-level stuff using SELinux/AppArmor. These don't require a managed runtime at all, and yet appear ("appear" being a critical point of courses) to solve this problem in a more robust way.
So, you're right of course, but I just want to point out that the JVM is very very widely used in another setting other than applets where it has a much better track record: serverside web applications.
I'm not sure we really know how to secure a desktop application / fat client platform yet.
It is inherently more secured in the same context. The JVM applet sandbox has to stand up to random code off the internet, whereas native code is almost only installed explicitly.
Remember ActiveX and how it was worse than Java applets?
It seems to me that the only reason we put up with JVM applets (whereas anyone suggesting we put up with people ActiveX would rightfully be laughed down these days) is because of that steady monotonous stream of crap about how much better Java is for security. It has dropped our collective paranoia far too low.
South Korea's situation is pretty unique/extreme in that way, though. At least I'm unaware of any other places that suffer a similar lock-in spiral. Except corporations, maybe.
Java is or was until very recently as anyone who has used it since 1995 will know and remember. Recent issue have arisen, hopefully Oracle is going to get its track record up to what Sun's was. Until then, a few bad recent reports for Java 7 will not wipe out decades of countless security reports for all of Windows Operating System and many relied upon Windows applications.
Java applets are still far more efficient and far more powerful and have far greater operability with Java web server software than even HTML5 will have.
Are you saying history in general is not pertinent to analysis? Is your rule only true for security issues or you do you feel that way about everything?
That's not true. All four major browsers can run CLR code through Silverlight [1] and depending on the statistics you use, the installation base for the plugin is in the same ballpark as Java, somewhere between 65% and 75% [2]. StatOwl even has Silverlight slightly ahead of Java at 69.7% vs 70.0% [3].
Of course, these are desktop stats. On mobile, it's a different story.
Set your browser to never auto-launch plugins, but require click to play.
If you're not already using ad-block, you will be amazed by how much it improves the performance of your general internet-surfing. So, besides security mindedness, there are already other good reasons for doing it.
> 56 percent of exploits blocked in Q3 use Java vulnerabilities.
So much for the idea of a managed language runtime being inherently more secure...