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.

Comments

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.
2:31 PM
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.
4:20 PM
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.

Cheers,
@c_APT_ure
6:12 PM
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?
7:10 PM
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)
("Mozilla/4\.0.\(Windows.(2003|Server.2008|Server.2008.R2|Vista|7)..\..\).Java/1|"JNLP/6\.0.javaws/1)

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!

Cheers,
@c_APT_ure
3:10 PM
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.
5:26 AM
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.

Cheers,
@c_APT_ure
9:15 AM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti...
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technica...
Read more