Attacks targeting vulnerabilities in the Java Runtime Environmentare anything but new. Several researchers have previously visited thistopic and the results have been some fantastic research. However, inrecent weeks the DeepSight Threat Analyst Team has been investigatingseveral Java issues resulting from a notable increase invulnerabilities reported affecting the Java Runtime Environment and itsassociated components.
The threat landscape has seen a dramatic increase in attackstargeting client-side vulnerabilities in recent years. Vulnerabilitieshave 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 primecandidate for attackers. With this in mind, it is not surprising to seemuch of the preliminary research into exploitation of environments likethe Java Virtual Machine manifest itself both in recently disclosedvulnerabilities and the consequent exploitation of these issues “in thewild.” This research has likely been (or will be) exacerbated by thefact that portions of Java are now open-source.
On January 16, 2007, Sun Microsystems published a vulnerability inthe Java Runtime Environment which was submitted to the Zero DayInitiative in December 2006. The issue is a heap-corruptionvulnerability which can be triggered when parsing a GIF image with awidth attribute of 0 (Sun Java Runtime Environment GIF Images Buffer Overflow Vulnerability).On June 26, 2007, a DeepSight honeypot was compromised by a maliciousWeb site targeting this vulnerability (among several others). Althoughseveral vulnerabilities in the Java Runtime Environment have beendisclosed previously, the DeepSight Threat Analyst Team had witnessedvery few cases of exploitation of these vulnerabilities in the wild,making this a notable event.
Coincidently on July 3, 2007, another heap-corruption flaw relatedto 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-overflowwhen 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 thecodebase parameter. This sudden influx of high-profile JREvulnerabilities provides some interesting insight into the currentstate of Java security. These issues suggest a shift (or at least anincrease in disclosure) to more contemporary research targeting theJava Runtime Environment.
Perhaps one of the most interesting points regarding vulnerabilitiesin the Java Runtime Environment is the advantage inadvertently providedfor attackers to leverage these vulnerabilities. First and foremost areJava Applets, which provide an excellent delivery vehicle forvulnerabilities affecting the Java Runtime Environment. Applets make iteasy for exploits targeting JRE’s to be delivered via malicious Websites as “drive-by” attacks. Applets can easily be hidden via an iframeor scaled down in size and placed in an inconspicuous portion of theWeb 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 sledand associated payload across a large portion of memory can be used toadd reliability to an exploit. This technique was initially pioneeredby Skylined for use in JavaScript when targeting browservulnerabilities, but similar techniques have since proven useful insidethe JRE as well (see JvmGifVulPoc.java).Additionally, by returning to the heap (particularly in the case ofstack-overflow vulnerabilities), an attacker is able to circumvent manyof the security mechanisms provided by Windows XP SP2 (DEP andSafeSEH). The ability to reliably bypass these security mechanismsmakes the exploitation of these vulnerabilities even more enticing.
The solution for mitigating these types of attacks is the oldstandard. First and foremost, ensure that Java is kept up to date withthe most recently available patches, along with IPS/IDS signatures.Whenever browsing an untrusted Web site, do so with caution and avoidenabling Java, JavaScript or other types of active content wheneverthey are unnecessary (for Firefox users there is a great extensioncalled NoScript that makes this process very easy).
Research into flaws affecting the Java Runtime Environment is not anew topic; however, the use of these issues in the wild is beginning tobecome a reality. The effectiveness of attack toolkits like MPack reiterates the dangers associated with client-side vulnerabilities. Dueto the intrinsic complexities associated with file format parsers, itis unlikely that these types of bugs will be hunted into extinctionanytime soon; a class of vulnerability of which Java appears to beanything but exempt.
Coincidentally, recently we have seen the disclosure of threehigh-profile vulnerabilities in the Microsoft .Net Framework. Two ofthese are of particular interest, the
Microsoft .Net Framework PE Loader Remote Buffer Overflow Vulnerability and the
Microsoft .Net Framework JIT Compiler Remote Buffer Overflow Vulnerabilitywhich are very reminiscent of the types of bugs disclosed in the JavaRuntime Environment, suggesting that the race to find these types ofvulnerabilities in .Net is on.