Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
The recent Java bug is in the SecurityManager. In other words, the hole threatens mainly applets or Web-delivered Java fat clients. I generally don't enable that stuff because little I use on the Internet can't live without it.
You probably know the SecurityManager as Java's "sandbox" introduced with Sun's marketing of Java Applets. It also has uses on the server. The SecurityManager is essentially Java's equivalent of SELinux or AppArmor, although it predates both. It tells Java which class can execute which "risky" functions (such as accessing the file system). You can implement a more coarse-grained version of much the same on a process level with Unix file permissions, the aforementioned AppArmor/SELinux, or a combination of technologies.
Developer soapbox: Why it's time to adopt applet alternatives and deprecate the Java Plug-in
Want more Java enterprise news? Get the JavaWorld Enterprise Java newsletter delivered to your inbox.
Some Java desktop applications like the Eclipse IDE are rarely Web-delivered and rarely even run in the SecurityManager. In other words, they're unaffected.
The people who will be most affected are Swing users, due to a few widespread applications dependent on client-side Java. Me, the only thing I use is WebEx. I keep a separate browser installed that I fire up only for WebEx.
The bug reduces some options for Java multitenancy (running applications from multiple providers in one JVM), but most multitenanted environments do not depend on a single JVM, using virtualization technologies instead.
The press has quoted some security expert as saying it will taketwo years to fix the Java SecurityManager. This isn't strictly true; the known exploit is patched. What's really meant here, on closer inspection, is that the SecurityManager couplings are a complicated mess. In other words, they were written by Sun.
While it may take two years to fully deploy a completely redesigned security subsystem for Java, I can't imagine it will take two whole years to fix. Folks have completely implemented the JVM and APIs in less than that time. However, if this is tied to a major release like Java 8, we're talking two years easy to be fully deployed. Moreover, as it stands, this will likely break compatibility for the people most affected (people who still using Swing, for example). Seeing that many of these applications are "dead code," haven't been updated in a while, and were broken by Java 7, the fix probably will come too late to save the long tail of client-side Java.
That said, because most Java applications are server-side trusted code that doesn't use the SecurityManager, it doesn't matter much to most people.
Java on the whole is still more secure than C. This seems like an absurd statement -- except that C code is vulnerable to buffer underruns and overruns, while Java code is not (due to the way memory is allocated and recovered). Most privilege escalations have been related to these two common bugs.