COMMAND

	Apache Jakarta Tomcat 3 URL parsing vulnerability

SYSTEMS AFFECTED

	Tomcat versions 3.3.1 and earlier

PROBLEM

	In   a   vulnerability   report    discovered    by    Jouko    Pynnönen
	[jouko@solutions.fi]    of     Online     Solutions     Ltd,     Finland
	[http://www.solutions.fi] :
	
	--snip--
	
	Certain kinds of HTTP  requests  containing  binary  null  or  backslash
	characters are parsed incorrectly by Tomcat's built-in web  server.  The
	following GET request causes Tomcat to output the directory  listing  of
	the web root under default installation:
	
	GET /<null byte>.jsp HTTP/1.0
	
	The following UNIX command can be issued to test the vulnerability:
	
	$ perl -e 'print "GET /\x00.jsp HTTP/1.0\r\n\r\n";' | nc my.server 8080
	
	If your server is vulnerable, the command will output a HTTP header  and
	the  directory  listing  even  if  there's  an   index   file   present.
	Furthermore, a backslash can  be  used  in  the  following  way  to  get
	information from otherwise inaccessible directories:
	
	$ perl -e 'print "GET /admin/WEB-INF\\classes/ContextAdmin.java\x00.jsp HTTP/1.0\r\n\r\n";'|nc my.server 8080
	
	This will output the contents of ContextAdmin.java.
	
	The servlet  engine  interprets  the  directory  listing  and  any  file
	retrieved in this way as a JSP page, which might  be  exploited  to  run
	arbitrary Java code under some imaginable  scenarios.  If  the  attacker
	can create a file whose name contains JSP tags somewhere under  the  web
	root, the code would be run when the directory  listing  is  fetched  in
	the way described above. Similarly Java code embedded in *.html  or  any
	other file can be compiled and run by an attacker.
	
	In the same way a remote user may force a *.jsp file to  be  interpreted
	as plain HTML, ie. retrieve the source of JSP files:
	
	$ perl -e 'print "GET /examples/jsp/cal/cal1.jsp\x00.html HTTP/1.0\r\n\r\n";'|nc my.server 8080
	
	This would output the source of the example JSP file.

SOLUTION

	A new version of Tomcat addressing this problem has been  released.  The
	fixed version 3.3.1a and additional information is available at
	
	  http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1a/
	
	According to the vendor, the problem only affects Tomcat used  with  JDK
	1.3.1 or earlier.