Do Devs Care About Java (In)Security?

In September InformationWeek published an article titled Java Still Not Safe, Security Experts Say. From that article by Matthew J. Schwartz:

Is Java 7 currently safe to use?

Last week, Oracle released emergency updates to fix zero-day vulnerabilities in Java 7 and Java 6. But in the case of the Java 7 fix, the new version allows an existing flaw--spotted by security researchers and disclosed to Oracle earlier this year--to be exploited to bypass the Java sandbox. In other words, while fixing some flaws, Oracle opened the door to another one.

In light of that situation, multiple security experts said that businesses should continue to temporarily disable all Java use, whenever possible. "There are still not-yet-addressed, serious security issues that affect the most recent version of Java 7," said Adam Gowdiak, CEO and founder of Poland-based Security Explorations, which initially disclosed the exploited vulnerabilities to Oracle in April. "In that context, disabling Java until proper patches are available seems to be an adequate solution," he said via email.

A month later I read a new article in InformationWeek titled "Oracle's Java Revival," also available as Two Years Later: A Report Card On Oracle's Ownership of Java by Andrew Binstock. The article appeared in the 29 October 2012 issue of InformationWeek, at a time when the security community continued to reel from repeated hammering of Java vulnerabilities.

I expected some mention of Java security woes in the article. About halfway through, with the word "security" not yet in print, I found the following:

In 2011, Oracle did not fare much better. The welcome release of Java 7 was marred by the revelation that it included serious defects that the company knew about.

Ok, maybe there will be some expansion of this idea? Shouldn't a terrible security record be a major factor affecting enterprise use of Java and a reflection on Oracle's handling of Java? Instead I read this:

I'm inclined to agree with James Gosling's revised opinion of Oracle's stewardship, that it's been good for Java...

However, the record is mixed in other areas...

Oracle's ambiguous relationship with the JCP and the OSS communities remain two other weak points.

That's it? Security pros continue to tell enterprise users to disable Java, and the development community is more concerned about features, personalities, and community relations?

I think the Java development community, and especially Oracle, must reevaluate their responsibilities regarding security. Otherwise, they may find themselves coding for a platform that enterprise users will increasingly disable.


Anonymous said…
You're comparing apples to oranges. Server-side Java (spring, hibernate, etc) and client-side Java (applets, local desktop apps, etc) are two completely different situations. Current vulnerabilities in Java are exclusively exploitable in the latter, not the former. There are other reasons to avoid writing server-side web apps in Java, but the reasons you listed here are not them.
Anonymous said…
Otherwise, they may find themselves coding for a platform that enterprise users will increasingly disable.

In our organisation, as I'm sure in many others, that's simply not an option. Some of our corporate applications require a client-side installation of Java, which often must be held back until that application has been certified with the latest patch revision. Changing the software used is non-trivial and, frankly, many within the enterprise itself don't understand the need (and there's not a lot of competition to change to anyway).

Yes, there's many workarounds. But they're workarounds, not solutions. As long as this is the case, Oracle has to know they've got a captive audience.
TomU said…
Why does everything always need to be black or white? You can't just disable Java in an enterprise that has many Java based applications in use, but updating Java is sometimes really hard, too. So we've implemented a proxy-based Java whitelist for "trusted sites" that need Java applets, much like the trusted sites model in IE for Active-X. I found many blocked malicious applets since, but not one drive-by infection from Java exploits. In additiona you might also want to whitelist executable downloads, in case some drive-by exploit still worked, the download of malware.exe would be blocked. There is also enough malware spreading using plain executables without browser-plugin exploits.

S A said…
@TomU: is your whitelist Java proxy all custom code or are you using COTS? Is it something you could share/opensource so we can all benefit?
TomU said…
We've implemented it with a custom policy rule on a COTS web proxy. But I guess you can do the same with many proxy products, maybe even some open-source like Squid etc.

You need to know all Java (JRE / Webstart) User-Agents in your environment and create a regex matching them all. I found that UA based is the only way to distinct Java applets (or webstart appl's) from other browser requests.

Here's a sample UA regex using "." instead of spaces. (may need adjustment for other environments)

The policy rule should be something like:
- if UA matches Java-UA-RE and domain is in whitelist --> allow
- if UA matches Java-UA-RE and domain is NOT in whitelist --> block

I hope this gives anyone an idea of how this could be done. Good luck!

Gray said…
Security should be as much a concern for developers as performance or reliability. It should not even have a special "oh, right, that, too" status, but be considered in the process of developing Java applications.
TomU said…
We're back to the first comment. You need to distinct between Java based web applications (server side) and Java based appliactions for workstations.

For the former you're right. This applies to web application security (SDL).

However, if you have Java based applications in an enterprise and you need to have Java enabled in your browser for the business (maybe even just for intranet apps), then you still have the risk of Java malware infections from drive-by (or "watering hole") attacks, where patching JRE on all workstations will always be too slow. This can be mitigated (or minimized) by the previously described Java whitelist approach on a web proxy.


Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia