CastleCops® - Denial-Of-Service holes in JDK 1.4.1

by Marc Schoenefeld

(html version at http://www.illegalaccess.org)

Several Java distributions (like the popular JDK 1.4.1 JRE from Sun) have been found to contain several locally Denial of Service vulnerabilities in java.util.zip.* system-classes exploitable by malicious applets and applications

Mar 10, 2003

Description:
Several Java distributions (like the popular JDK 1.4.1 JRE from Sun) have been found to contain a locally exploitable Denial of Service. The problem appears difficult to exploit, but hackers have a history of discovering and releasing exploit code for exploitable flaws. The techniques described here have been presented at the Blackhat Windows Security 2003 conference. The following threats appear on the whole range where java technology is present:

A malicious user or an attacker could insert the described exploitable API code to force JVM crashes in the ISPs runtime environment. This will cause outage of the JSP / servlet service the JVM is running for. This has been tested with Tomcat 4.1.18 with security options turned on. There is not only a threat for server-based services, furthermore a malicious applet containing the code exploiting the vulnerable classes could crash browser software like Internet Explorer, Netscape Navigator, Lotus Notes that have Java functionality enabled.

Analysis:
Java DK 1.4.1 has entry points to native libraries. These entry points can be called with parameters (java simple types or objects). If an object value is set to null and the native routine does not provide appropriate check for null values, the JVM reaches an undefined state and typically ends of in a JVM crash. The following proof of concept code describes the problem stated above. If you are interested for details about JVM security see the presentation of Marc Schoenefeld at Blackhat USA 2002 and LSD-PL at Blackhat Asia 2002. In this specific case there seems to a protection against buffer underflow in the vulnerable classes, which can be disabled by a special combination of the accompanying parameters, which cause via an underflow condition. If the injected buffer can be used for shell code injection is still under investigation.

This vulnerabilities can be exploited in the following scenarios if the vulnerable method is called in a java application, there is low to medium risk, because attacker normally needs access to local file system, the risk if classes are loaded dynamically from the network and the jar-files are infected with the exploit in a java servlet or java server page, there is medium to high risk, because attacker normally needs access to the webroot directory. After injecting an infected servlet/server page , the attacker calls it via http and the servlet engine (tested with tomcat 4.1.18) dies with an JVM crash. Unfortunately the -security parameter has no effect, because java.util.zip.CRC32 is a trusted class. in a java servlet, there is high risk, resulting in a denial-of-service of the browser software. This has been tested with several browsers and JDKs plugged in on W32 and Linux, including popular platforms like Internet Explorer 5/6, Mozilla and Konqueror browser utilizing Java Plugins like the current JRE 1.4.1 or JRE 1.3.1.

Continued


	2002-2008 � Computer Cops LLC dba CastleCops®. All rights reserved. Acceptable Use Policy. Use signifies your agreement. 214ppm 0.210s (0.008s) Making cybercriminals unhappy since 2002*