Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

Java is still the most secure widespread runtime

Who cares about Java's applet security flaw, Android is client-side's future anyway

By Andrew C. Oliver, InfoWorld, 01/31/13

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.

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.

Two years until a fix? Not likely

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.

If SecurityManager is broken, should we go back to C?

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.

For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.