Far gone are the times when truly remote server-side vulnerabilities were the most popular vectors for compromising machines and attacking organizations. More than 93 percent of vulnerabilities exploited in recent years have been client-side security flaws, as discussed in the Symantec Global Internet Security Threat Report. They are used in both targeted attacks and massively widespread drive-by attacks to create botnets. One type of these sorts of vulnerabilities is browser and browser-related issues. In many cases they merely require a victim to follow a single link to become compromised. There is a continuous race between browser developers, vulnerability researchers, and exploit writers. In this year’s Pwn2Own contest at the CanSecWest Applied Security Conference, all of the most popular browsers except Google Chrome were successfully exploited on the first day. The list included Apple Safari on Mac OS X and iPhone, as well as Internet Explorer 8 and Mozilla Firefox on Windows 7. The technically impressive exploits used in these attacks successfully sidestepped modern memory protection and security mechanisms, including DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization). While these events were widely discussed in the security community and media, there were a few very interesting and related developments that have gone rather unnoticed. These involved vulnerabilities affecting the Java Runtime Environment that can also be exploited through the browser. The vulnerabilities in question are tracked by two Bugtraq IDs (39075 and 39065) and were first described in the Zero Day Initiative advisories (ZDI-10-051 and ZDI-10-056). Unlike the widely discussed issues published recently by Tavis Ormandy and Ruben Santamarta, the discussed vulnerabilities were disclosed after Oracle patched them in a Java update. However, on certain systems that ship with custom versions of JRE, these issues may still constitute zero-day threats. Both of these vulnerabilities, discovered by a Java security expert Sami Koivu, can be classified as privilege-escalation issues within the Java Runtime Environment (JRE) and when exploited through Java applets in a browser they pose a remote threat. While the consequences of successful exploitation are the same as in the case of a browser memory-corruption issue, these flaws are of different nature and stem from logical flaws. The properties of these types of issues make them what could be called, from an attacker’s perspective, “ideal” client-side vulnerabilities. We took a detailed look at both of the issues and were able to develop reliable proof-of-concept code that worked in multiple browsers on multiple platforms. After we gained a better understanding of the properties of such issues in the process, we are confidently expecting exploits of these issues to appear in the wild. The first property, which makes such issues attractive for attackers, stems from the fact that they do not rely on any memory-corruption conditions; hence, the exploits are extremely reliable and do not have to cope with memory protection mechanisms. ASLR and DEP-based protections will not protect against the exploits. The Google Chrome browser’s sandbox, which effectively stopped Pwn2Own contestants, is also of no use in this case—similar to the Internet Explorer Protected Mode sandbox. These are design flaws that allow restricted Java code to escape the Java security sandbox and execute in the same environment it was designed for, but with full user privileges. Not crashing the browser or expressing any other suspicious behavior, these types of issues can be exploited completely silently, leaving the user completely unaware or at least unsuspecting. Furthermore, unsuccessful exploit attempts will also not result in any unexpected behavior that would be noticeable to the user. Another uncommon vulnerability feature sought after by attackers is platform and browser independence. One of the things that makes Java so popular among academic and open-source communities (as well as software vendors) is its platform-independent design and the availability of the environment for multiple operating systems. Unfortunately, this also means that vulnerabilities are usually present on different platforms and exploits are also highly platform independent. The possibilities of Java are truly great and so is the potential of the exploits. Because payloads for these types of issues are implemented purely in Java, they benefit from all the goodness of the platform. Implementing payloads is extremely easy and has virtually no limitations, which is usually not the case for memory-corruption bugs. Additionally, most modern browsers support Java through browser plugins and delegate execution of Java applets to the underlying JRE. This makes all common browsers prone to attacks exploiting the issues discussed here. The nature of these issues makes detection attempts difficult. The exploit and payload are delivered in compiled byte code, the parsing of which usually lying outside of the possibilities of security software. Also, there is no explicit abnormal behaviour within malicious applets and more highly privileged tasks may be legitimate in the case of signed or approved applets, which increases the chances of false-positive alerts during detection. It should also be noted that the patch distribution process and update habits of Java users leaves a lot to wish for. Many vendors maintain their own customized versions of JRE and provide updates with severe delays. Additionally, many users do not update the environment and a lot of machines run multiple versions of the environment that were shipped with different products and unclear update procedures. So how do you stay protected? The first thing to do is to make sure your Java software is up to date. Additionally, users and administrators should consider disabling browser support for Java applets if it is not required for business. Other standard mitigation strategies, such as running all software with minimal privileges and not following untrusted links, also apply.