24

First it was Apple, now it's the US government...

How serious is this "unspecified vulnerability"? Should all users be disabling Java until we know things have been patched?

Edit:- Some people have asked that the following distinction is made: Java is completely different to Javascript, so any recommendations below pertain only to Java.

Django Reinhardt
  • 938
  • 2
  • 8
  • 20
  • 10
    Disable java plugins but keep java itself. – CodesInChaos Jan 12 '13 at 20:45
  • Ditch Java on anything that doesn't need it to reduce your vulnerability surface. For example, on a network of 50 computers, there probably are only 6 people who need it. Reduce your workload by locking Java down to just those workstations and you'll be much happier in the long run. Same goes for your home system. Remove it, unless your bank requires it for one of their supposedly secure applets. Java != JavaScript. – Fiasco Labs Jan 12 '13 at 23:09

3 Answers3

35

Apple apparently takes this seriously, since they "disabled Java" in users' computers, which is a rather drastic move. This actually smells like a pretext to kill off the technology, as part of a wider strategy.

For this specific hole, there are a few details there. It is all about the Java applet model. To understand:

  • Java is a programming language and a huge library of code, all running within a virtual machine. The VM means that code is much easier to port between architectures. So far so good; the same applies to several other frameworks, including .NET.

  • The strong typing of Java and the VM conceptually allows an extra feature, which you cannot have (at least not easily) with more bare-metal languages like C++: the possibly of safely running potentially hostile code. With C or C++ or assembly or whatever, such a feat requires some help from the hardware and the operating system (namely the privilege levels of protected mode, or, for the extreme cases, specialized virtualization opcodes). Strong types and the VM allow for a software-only sandbox solution, which could be integrated in, for instance, a Web browser.

  • Java applets are just that: a sandbox for running Java code which is downloaded from the Web, as part of a Web page. However, the people at Sun/Oracle didn't know where to stop, and were a bit too eager. Since sandboxed code is severely limited in what it can do, there are only two choices: learn to live with limitations (that's what Javascript developers do), or include in the sandbox an escape mechanism allowing some applets to do out-of-sandbox things, such as reading and writing files, opening arbitrary sockets, and running native code. The VM allows that, provided that the applet asks nicely, which entails fine-grained permissions, a digital signature and an explicit authorization popup.

  • It turns out that managing this system of "permissions" is very hard to do for the VM and library; namely, the library is very rich in code which offers access to various OS facilities, and they must all be plugged without forgetting any. There are hundreds, maybe thousands of "sensitive calls" to care about. The long history of security holes in Java is a testimony to the nigh impossibility of the task. If the competing technology from Microsoft (Silverlight, built over .NET) seems a bit less impacted, it is mostly because it is much less used worldwide, giving it far less exposure.

For the time being, the safest thing to do is to disable support for Java applets in your browser. Note that Java applications, and in particular anything which runs server-side, are not impacted.

The problem of safely running hostile code, while simultaneously maintaining rich functionality and fine-grained access control, is not a new problem. What this yet another Java mishap shows is that this old problem is still unsolved.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    Yeah, it's not like we didn't see the same kind of issues allowing rooting via exploits in the dalvik VM (android) too, not to mention, IOS'es sand boxing also has such errors. And I don't think any javascript implementation is immune. So why do we assume that any way of running remote code is safe? – ewanm89 Jan 12 '13 at 20:43
  • 7
    We _want_ to run hostile code. It would be too disappointing if it was not possible. So we will try. Ever and again. – Thomas Pornin Jan 12 '13 at 20:45
  • 8
    It may also be worth mentioning that Java != JavaScript, and that they're completely distinct languages. – Polynomial Jan 12 '13 at 22:05
  • @ThomasPornin - We will all sell our souls to the devil for convenience. – Fiasco Labs Jan 12 '13 at 23:14
  • 2
    Apple did not disable Java. Whilst Java 7 Update 10 was blacklisted by Apple XProtect, Java 6 Update 37 remained usable. – Graham Perrin Jan 15 '13 at 19:25
  • funny to see that XBAP isn't listed here (or anywhere else on Sec.SE) ... it would have more permissions than Silverlight, and possibly the same vulnerabilities as Java. Guess it really is off the radar of *everyone* – makerofthings7 Jan 23 '13 at 18:17
3

The Department of Homeland Security (DHS), US-CERT and the National Security Authority in Norway recommended disabling Java as a quick fix because exploit code was present in the wild. It was not a move against Java. After the patch came out it was just advised to apply the patch.

On the other hand, there's Apple who has a more aggressive stance against Java by actually disabling it. In the past, Apple maintained it's own custom version of Java that was lagging behind the official release. The Java vulnerability that was exploited by the OS X Flashback malware was patched in the official version a few months prior to September 2011, when Flashback started infecting Mac OS.

After fighting the defeating Flashback, Apple learned a lesson and changed it's policy by:

  • Allowing the official version of Java on Mac OS.
  • Removing the statement that "Mac OS is invulnerable to malware" from it's website.
  • Automatically disabling Java from the browser after 35 days of no usage and asking the user for permission to enable it.
Cristian Dobre
  • 9,797
  • 1
  • 30
  • 50
2

yes you should disable java , as developers have found a critical venerability in java that helps hackers in many ways.So in recent update Apple has also removed java from its "safest" MAC OS X

Skynet
  • 598
  • 5
  • 12