The Java SE 7 Update 10 was introduced with additional certified system configurations like Mac OS X 10.8, Windows Server 2012 (64 bit), Windows 8 Desktop Mode and additional security enhancements. The JDK 7 Update 10 had security enhancements that included the property to disable any Java applications from running in the browser. This feature could be available through the Java Control Panel or via the Windows Platform using the command line install argument. The security enhancement enabled a user to adjust the desired level of security for unsigned Java applets, JavaFX applications and Java Web Start applications that run through a browser. In addition, a critical update was the introduction of new dialogs for warnings on insecure and expired Java Runtime Environments which may be a serious security problem. These dialogs directly indicated that the JRE needed to be updated. The bug fixes introduced with Java 7 Update 10 were the Java command and classpath documents implementation which described how the wildcard character(*) could be used in the classpath element to expand into a list of jar files.
Along similar lines, we had the Java 7 Update 11 which had patches for the critical security alert CVE-2013-0422. This vulnerability affected Java running in web browsers and was not applicable to Java running on embedded and standalone Java desktop applications, servers, and Oracle based server software implementations. This update included a change to the default Java Security level from Medium to High. The best part about this fix was when the High setting was switched on, the user was prompted before any unsigned Java applet or Java Web Start application was run. The flaw which was present prior to the Java 7 Update 11 could be remotely exploited over the network without authentication. For a successful exploitation, a user who would be using a flawed version of Java could be compromised if he visits a malicious web page which leverages these vulnerabilities.
For all the updates, the security baseline basically refers to the Java Runtime Environment version(JRE). This JRE is the main component of Java, which we download and consists of the Java Virtual Machine(JVM), Java platform core classes and libraries. The major security feature involved in Java is Sandboxing. The Java Sandbox prevents applets from performing malicious activities on the host system. At the root, the security depends on the Byte Code Verifier, the Class Loader, and the Security Manager. Collectively, these modules perform load and run time checks to restrict file and network access from malicious apps. The Byte Code Verifier allows it to automatically check untrusted, outside code before actually running it. During the compilation process of a Java program, the Java byte code is verified by the Verifier before it actually runs. The next security baseline which is the Applet Class Loader determines when and how an applet can add classes to a running Java environment. The Security Managers purpose is to act as a consultant and help the code in the library whenever a dangerous operation is about to be carried out.
The version Java 7 Update 11 had a vulnerability that allowed it to bypass all security mechanisms in the Java browser plugin. This allowed an attacker to execute arbitrary code using JRE in a computer. This was also founded by Adam Gowdiak, CEO of a Security Exploration. Adam was quoted saying on the Full Disclosure Mailing List “What we found out and what is a subject of a new security vulnerability (Issue 53) is that unsigned Java code can be successfully executed on a target Windows system regardless of the four Java Control Panel settings described above. Our Proof of Concept code that illustrates Issue 53 has been successfully executed in the environment of latest Java SE 7 Update 11 (JRE version 1.7.0_11-b21) under Windows 7 OSand with “Very High” Java Control Panel security settings.” Hence, according to Adam, the recent updates from Oracle for Java did not prevent silent exploits from privilege escalation. The non-technical users, which compromisethemajorly ofpeople,have to rely on the “AcceptAll” fundamentals (Accept All option for pop ups) to make their life easier. But at the same time, this allows the malicious applets to execute on the client side which ultimately would result in the execution of unsigned Java code on the Windows platform. The Proof of Concept was also provided by Gowdiak to Oracle but has not been yet disclosed by the Oracle Team, hence we cannot demonstrate a practical working for the same. Gowdiak was completely able to bypass the Java security sandbox through the Java 7 Update 11 vulnerability. As a result, any attacker would be able to compromise the system through this vulnerability. The Java Control panel security settings to provide control on access of unsigned applets introduced in Java 7 Update 11 were actually bypassed through Gowdiak’s exploit. The four-option panel enabled a user to set the Java security environment to low, medium, high or very high. The “very high” security feature blocked unsigned applets from running outside of the sandbox environment. These two new bugs did not exploit the partial patch of the “MbeanInstantiator” flaw. For those who are unaware of the MbeanInstantiator flaw, it basically allowed content combining Java Management Extensions MBean components and sun.org.mozilla.javascript.internal objects to call the ‘setSecurityManager()’ function to elevate a user’s privileges. The com.sun.jmx.mbeanserver.MBeanInstantiator.find Class method allowed an attacker to retrieve Class references of any package. Using a reflection method (API) recursively, an attacker can then bypass security checks and use this to run privileged code. The situation was very critical and the Department of Homeland Security recommended people to disable Java for the browsers. For Firefox users, it was recommended that they install the NoScript extension which could enable them to secure their computer against attacks from insecure websites. For the masses, I would suggest to update your Java to the latest version and switch on the automatic updates. This would, at the very least, be a perimeter security against older malicious exploits. Reference Links http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1489 http://www.zdnet.com/java-update-doesnt-prevent-silent-exploits-at-all-7000010422/ http://www.scmagazine.com.au/News/330453,java-still-unsafe-new-flaws-discovered.aspx http://www.informationweek.com/security/application-security/java-security-work-remains-bug-hunter-sa/240147150 http://thenextweb.com/insider/2013/01/28/new-vulnerability-bypasses-oracles-attempt-to-stop-malware-drive-by-downloads-via-java-applets/ http://seclists.org/fulldisclosure/2013/Jan/241 http://blogs.computerworld.com/cybercrime-and-hacking/21664/understanding-new-security-java-7-update-11 http://www.java.com/en/download/faq/whatis_java.xml http://www.oracle.com/technetwork/topics/security/javacpufeb2013-1841061.html http://www.oracle.com/technetwork/java/javase/7u10-relnotes-1880995.html http://searchsecurity.techtarget.com/news/2240176367/Java-vulnerabilities-continue-to-crop-up-with-Java-7-Update-11-release http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-1896849.html http://www.javaworld.com/javaworld/jw-05-1997/jw-05-security.html http://www.securiteam.com/securitynews/5FP2Y2A97A.html http://www.technize.net/download-java-7-update-11-offline-installers/ http://www.darkoperator.com/blog/2013/1/12/pushing-security-configuration-for-java-7-update-10-via-gpo.html
