New Trend in Attacking the Java Runtime Environment?
Attacks targeting vulnerabilities in the Java Runtime Environment are anything but new. Several researchers have previously visited this topic and the results have been some fantastic research. However, in recent weeks the DeepSight Threat Analyst Team has been investigating several Java issues resulting from a notable increase in vulnerabilities reported affecting the Java Runtime Environment and its associated components.
The threat landscape has seen a dramatic increase in attacks targeting client-side vulnerabilities in recent years. Vulnerabilities have been exposed in a variety of applications including media players, Web browsers, ActiveX controls and mail clients, to name just a few. The ubiquitous nature of the Java Runtime Environment makes it a prime candidate for attackers. With this in mind, it is not surprising to see much of the preliminary research into exploitation of environments like the Java Virtual Machine manifest itself both in recently disclosed vulnerabilities and the consequent exploitation of these issues “in the wild.” This research has likely been (or will be) exacerbated by the fact that portions of Java are now open-source.
On January 16, 2007, Sun Microsystems published a vulnerability in the Java Runtime Environment which was submitted to the Zero Day Initiative in December 2006. The issue is a heap-corruption vulnerability which can be triggered when parsing a GIF image with a width attribute of 0 (Sun Java Runtime Environment GIF Images Buffer Overflow Vulnerability). On June 26, 2007, a DeepSight honeypot was compromised by a malicious Web site targeting this vulnerability (among several others). Although several vulnerabilities in the Java Runtime Environment have been disclosed previously, the DeepSight Threat Analyst Team had witnessed very few cases of exploitation of these vulnerabilities in the wild, making this a notable event.
Coincidently on July 3, 2007, another heap-corruption flaw related to image parsing in the Java Runtime Environment was disclosed (Sun JDK JPG/BMP Parser Multiple Vulnerabilities). This issue was due to insufficient validation when parsing ICC profiles (a cross-platform way to describe color spaces for displaying images). On July 9, 2007, eEye disclosed a trivially exploitable stack-overflow when parsing JNLP files (Sun Java Runtime Environment WebStart JNLP Stack Buffer Overflow Vulnerability). This vulnerability is due to a lack of bounds checking when parsing the codebase parameter. This sudden influx of high-profile JRE vulnerabilities provides some interesting insight into the current state of Java security. These issues suggest a shift (or at least an increase in disclosure) to more contemporary research targeting the Java Runtime Environment.
Perhaps one of the most interesting points regarding vulnerabilities in the Java Runtime Environment is the advantage inadvertently provided for attackers to leverage these vulnerabilities. First and foremost are Java Applets, which provide an excellent delivery vehicle for vulnerabilities affecting the Java Runtime Environment. Applets make it easy for exploits targeting JRE’s to be delivered via malicious Web sites as “drive-by” attacks. Applets can easily be hidden via an iframe or scaled down in size and placed in an inconspicuous portion of the Web site, making them difficult to notice.
Second, due to the way Java allocates heap-memory, scenarios where the attacker can repeatedly “spray” the heap with a nop sled and associated payload across a large portion of memory can be used to add reliability to an exploit. This technique was initially pioneered by Skylined for use in JavaScript when targeting browser vulnerabilities, but similar techniques have since proven useful inside the JRE as well (see JvmGifVulPoc.java). Additionally, by returning to the heap (particularly in the case of stack-overflow vulnerabilities), an attacker is able to circumvent many of the security mechanisms provided by Windows XP SP2 (DEP and SafeSEH). The ability to reliably bypass these security mechanisms makes the exploitation of these vulnerabilities even more enticing.
The solution for mitigating these types of attacks is the old standard. First and foremost, ensure that Java is kept up to date with the most recently available patches, along with IPS/IDS signatures. Whenever browsing an untrusted Web site, do so with caution and avoid enabling Java, JavaScript or other types of active content whenever they are unnecessary (for Firefox users there is a great extension called NoScript that makes this process very easy).
Research into flaws affecting the Java Runtime Environment is not a new topic; however, the use of these issues in the wild is beginning to become a reality. The effectiveness of attack toolkits like MPack reiterates the dangers associated with client-side vulnerabilities. Due to the intrinsic complexities associated with file format parsers, it is unlikely that these types of bugs will be hunted into extinction anytime soon; a class of vulnerability of which Java appears to be anything but exempt.
Coincidentally, recently we have seen the disclosure of three high-profile vulnerabilities in the Microsoft .Net Framework. Two of these are of particular interest, the Microsoft .Net Framework PE Loader Remote Buffer Overflow Vulnerability and the Microsoft .Net Framework JIT Compiler Remote Buffer Overflow Vulnerability which are very reminiscent of the types of bugs disclosed in the Java Runtime Environment, suggesting that the race to find these types of vulnerabilities in .Net is on.
Posted by Darren Kemp on July 23, 2007 05:00 AM