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

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

 

Siddharth Syal