Tod Beardsley, Engineer at Rapid7, said: "Users should disable the Java plug-ins for browsers. Unlike Flash, HTML5 or PDF, no technology is ubiquitous on the Web ... Disable unnecessary functionality provided is good advice - This reduces the possibility of attack s ".
Such advice can be very useful for end users, but not for companies because u na series of common business applications such as conferencing and collaboration are based on the Java runtime, and some data center applications running on Java, says Scott Crawford, research director at analyst firm Enterprise Management Associates industry.
That was not the case a few years ago. Wolfgang Kandek, CTO of Qualys, says that web browsers used to be a prime target for attackers until browser makers developed better security defenses. Attackers turned their attention to other programs as Flash and PDF, but Adobe has put a lot of resources on strengthening its products. now seems that Java is being targeted.
SystemsExperts' Hill see many organizations that are eliminating dependencies of Java applets. "Now people are developing rich web applications with Ajax techniques for Java that run on the server and not on the client side," he says.
How can you ensure Java?
A little background.
Oracle, starting Sun, has advanced the development of the Java ecosystem in several areas, including the programming language on the server side and the JRE widespread client side, but the attackers continue to expose serious security vulnerabilities in the JRE . Most of these vulnerabilities are limited to the most common platforms such as MacOS and Windows, but since Java is used in a wide variety of platforms for client software, the impact of vulnerabilities can not be understood well.
Here we will try to talk about the latest series of Java security vulnerabilities and provide some measures to improve the security of Java.
In recent times, it seems like Oracle releases a patch for the vulnerability discussed more recently Java, attackers are one to exploit. Another critical vulnerability was identified in September 2012 , allows an attacker to exploit a security feature core the Java JRE, type safety, to escape the Java sandbox. An attacker could completely compromise the security of a system by exploiting this vulnerability. Worse, the Java security patches may be giving more opportunities for attackers to exploit: It is believed that the JRE vulnerability that was reported in August 2012 may have been introduced by a previous patch. Error in AWT subcomponent Java also could allow code execution on the local system, avoiding the litter box and result in a system being compromised. When the upgrade of Oracle software exposes new security vulnerabilities, the strength of the cycle development life Java software comes into question. Not all errors are preventable, but it seems clear life cycle development of stronger security is needed to help prevent the introduction of new Java errors.
The reality is that the Java security problem is not going away. Remain vulnerabilities found, exploited and patched by Oracle with variable speed and efficiency. To be fair, the software vendor is facing a difficult task, as it seeks encourage the development of Java to try to keep it secure. has joined Oracle's Java technical debt, resulting in an increasing number of vulnerabilities.
Methods for securing Java.
As mentioned above, some experts recommend disabling Java, but has also been seen that it is easier said than done. Although there are viable alternatives to the software as Adobe Reader, no real alternatives now exist for the Java Runtime Environment. Reality is that many enterprise applications are based on Java, for many organizations, not just disable Java an option.
That said, the standard advice to ensure any client software also apply to JRE, including not install (or uninstall) the JRE if necessary, keeping the JRE to date, removing old versions and patch deployment and security management controls in the client-side end.
But consider additional controls specifically for Java. For example, a company can run the JRE software and necessary in its own virtual machine, run the JRE with reduced permissions (which should be a default policy regardless) and allow the white list applets Java to run on the JRE with Noscript or similar software. Toolkit Enhanced Mitigation Experience can be used to more securely configure the JRE on Windows systems.
Companies can also compile Java code into native executables to avoid problems with the JRE, but this action would deny the "write once, run anywhere" benefit of using Java. Given that most Java applets run on either PCs or Macs, this could be a reasonable measure for some organizations, but it would not work for all platforms that run Java.
Companies can also compile Java code into native executables to avoid problems with the JRE, but this action would deny the "write once, run anywhere" benefit of using Java. Given that most Java applets run on either PCs or Macs, this could be a reasonable measure for some organizations, but it would not work for all platforms that run Java.
If I could be compiled, this would help reduce the number of systems in a company that has a JRE installed only by an application. All these methods require significant effort, but could reduce the risk to an acceptable level for most companies.
The Java Runtime Environment was the result of the need to facilitate cross-platform development. Unfortunately, the reputation of the Java ecosystem has had significant success due to the large number of security vulnerabilities exposed in the JRE and lifecycle software development Oracle. Whilst organizations should think long and hard about committing to Java, fortunately, there are ways for companies to limit the risk to end by the JRE if it is a business necessity, and if not absolutely necessary, however, should not be installed.
You need to be a member of Diplo Internet Governance Community to add comments!
Join Diplo Internet Governance Community