0-Days and the "Nuclear" Option

| 2 Comments

There's a new Java 0-day exploit circulating in the wild, supported by a Metasploit module, among others. In response to this new vulnerability, I received the below email from a security vendor overnight:

I found their email to be a bit alarming, since it suggests what I would consider to be a "nuclear option" approach to the problem. Unfortunately, I find it oddly lacking in reasonable context, risk analysis (which rarely can be universalized, but must rather be performed on a per-entity basis), as well as to be a near-impossible suggestion to implement (not technically, but rationally).

Specifically, the questions is this: Can an individual or business reasonably and rationally disable Java across all browsers? While the short, technical answer might be "yes," I think the overall answer is "probably not." Consider:

1) There is significant reliance on Java-based, browser-hosted applications.

There are myriad examples, but three biggies come to mind right away. First, GoToMeeting - a popular web conference platform - makes heavy use of client-side Java. It's a mainstay in the vendor world for presentations, demos, and training. True, you can potentially disable Java in your browser and then manually execute the GTM client, but is this a reasonable expectation for attendees or less technical users? Probably not.

Second, I've yet to see an analysis of the impact on the Android mobile operating system. While Android itself is based on Linux, almost its entire application ecosystem is based on Java. In this case, the Java implementation is specialized, and so it may yet be determined that this specific vulnerability doesn't impact it. Nonetheless, these apps tend to behave in a very browser-like manner (as thin clients, really), and the thought that you could somehow disable Java across all Android devices is a absurd.

Last, an open question... are Blu-ray devices making use of embedded Java today? I found this presentation that suggests that Blu-ray includes a Java implementation. If this is true, then is it also vulnerable to this latest vulnerability (or a variety of others)? Since many Blu-ray devices are internet-enabled, what sort of risk does this pose to consumers? Certainly, disabling Java in this environment would not be reasonable, realistic, or feasible.

2) Inadequate risk analysis is available in each entity's context.

It's rather absurd for anyone to send out a universal "disable Java" message, because there is no way to determine universally whether or not the vulnerability really represents a significant risk in each individual's or business's environment. Note that we've had similar calls in the past about technologies like Adobe Flash, too. Such a call is really FUD-based and overhyped.

An appropriate step for businesses is to first understand the vulnerability itself, how prevalent it is in their environment, and what is potentially exposed as a result of attacks. Then appropriate remediations can be considered, up to and including wholesale disabling of the platform, with the decision then following accordingly. This analysis should balance what could be compromised against the cost of disabling the technology. Also, there is potentially a very valid "wait and see" case to be made, since nothing official has been announced from the maintainers of Java (presumably Oracle, which bought Sun a couple years back). Until more is learned, it's a bit senseless to jump to the most extreme option(s). Characterized the risk represented by enumerating threats, vulnerabilities, and probable losses, and then make a decision.

3) There are technical limitations to disabling a core technology like Java.

Last, and perhaps most important... your ability to disable Java may be limited. Do you have adequate tools in place to update the browser settings on all servers, desktops, and mobile devices? Don't forget about those shiny new BYOD policies you have out there... maybe you have some basic MDM/MAM applications deployed to personally-owned devices, but do these tools allow you change browser configurations, and/or to disable a core technology like Java? Moreover, do your policies actually allow you the "nuclear option" of shutting down something potentially core to the functioning of the device (thinking back to Android's reliance on Java)?

Even if the best option were to shutdown Java in the browser, I think it's unlikely that it could be done today. Not only is it too central to many applications and functions, but the ramped-up incursion of privately-owned devices into the enterprise means that it's likely not even technically feasible. I'm sure I could even come up with some pretty compelling extreme movie-plot points that would make this scenario even more scary (e.g., using a Java 0-day, attackers compromise Android devices, including those that haven't been officially added to the enterprise environment through BYOD policies and practices, and then begin using these Android devices to automate multi-point attacks, such as through wifi eavesdropping, wifi attacks on weakly defended wireless networks, and through compromise of applications, email, file sharing and collaboration tools, etc.).

The bottom line is this: Don't panic - analyze. Undertake reasonable measures to protect yourself and your organization, but not at the expense of getting work done. Educate users - realistically and without hype - about the threat posed, and provide reasonable, actionable guidance on how they can better protect themselves. Beyond that, a "wait-n-see" approach is most likely your best fallback position.

2 Comments

I agree with your post except for Flash. Having been victimized by a Flash drive-by, I now disable Flash for all sites by default and only enable for sites I specifically trust (very few). My computer is more secure than most and some anti-malware kicked in, but it was too late. So I have no faith in Flash.

Make no mistake, I don't trust Flash, either. It's a fully loaded embedded OS, complete with raw sockets. No good can (or has) come of that.

About this Entry

This page contains a single entry by Ben Tomhave published on August 29, 2012 10:03 AM.

"Stand Your Ground" - A Case for GRC was the previous entry in this blog.

3 Simple Ideas to Unbalance the InfoSec Status Quo is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives

Pages

  • about
Powered by Movable Type 6.3.7