Results 1 to 4 of 4
-
06-08-2003, 12:44 AM #1Web Hosting Guru
- Join Date
- Dec 2001
- Location
- QLD, Australia
- Posts
- 285
[Full-Disclosure] Apache 2.x APR Exploit
Hey there,
Just posted to Full-Disclosure. Thought it would be adviseable that Apache 2.x users are made aware of it. Not sure of a fix yet, no doubt it will be made available in the next few days.
I had planned to write this tool in C for the sake of using native
functionality like crypt(3) to support digest authentication. I'd also
planned to support intermediate proxies, but a determined user can
implement this via various tunneling applications with minimal
complications, and I don't need to make this too script-kiddie friendly.
The details of each exploit vector are as follows:
* mod_proxy
mod_proxy outputs a simple message when a connection has failed that
includes the host name of the intended destination. It accomplishes this
via the vulnerable apr_psprintf() function. This leads to a crash if the
Host header is extremely long.
* mod_dav
Certain methods of accessing a DAV repository may enable attacker-supplied
input to be passed as a parameter to apr_psprintf() as part of an "Invalid
namespace" error. This results in the crash of the child handling the
request.
* Others
NOTE: mod_dav is also impacted by this exploit, but the exploit vector
above specifically targets it.
Many modules format the hostname of the server into buffers via the
apr_psprintf() function. The hostname is under the attacker's control if
"UseCanonicalName Off" is in place. Via a long HTTP/1.1 "Host" header, it
becomes possible to cause these modules to crash.
*** NOTE: Some people have assumed that the Apache LimitRequestFieldSize
directive would protect them from exploitation, so long as they did not
have mod_dav installed. This is not correct, as the Apache HTTP Server may
take:
GET / HTTP/1.1
Host: a
Host: b
And internally convert it to:
GET / HTTP/1.1
Host: a, b
The same is true for longer headers. So, ten such headers of 2000
characters each bypasses the default LimitRequestFieldSize directive, but
still exploits the vulnerability.
Workarounds
* LimitXMLRequestBody 2000 in your configuration file for any servers with
DAV enabled. These can be identified by the string "DAV/2" in their server
signatures in most cases.
* The following pair of lines:
LimitRequestFields 15
LimitRequestFieldSize 800
will temporarily block the mod_proxy exploit.
* Such a rash workaround is not required for the other modules, where a
simple:
UseCanonicalName On
does the trick. It was recently pointed out to me that there was an error
in my previous post regarding this. It incorrectly stated that
UseCanonicalName *Off* fixed the flaw. In reality, this *opens* one of the
exploit vectors. However, I believe it was clearly identified in the other
parts of my post, and this has now been corrected. Without making you wait
any longer...
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Stuart
P.S.
Author Info:
# Contact:
# E-mail: mattmurphy@kc.rr.com
# Web: http://www.techie.hopto.org/
# AIM: NetAddict4109
# or for the Windows folk among us:
# aim:goim?screenname=NetAddict4109
-
06-08-2003, 01:09 AM #2WHT Addict
- Join Date
- Nov 2002
- Posts
- 151
Isn't this fixed with 2.0.46?
-
06-08-2003, 02:10 AM #3Web Hosting Guru
- Join Date
- Dec 2001
- Location
- QLD, Australia
- Posts
- 285
Hey there,
Not sure, we personally stick with the 1.3.x tree.
Stuart
-
06-08-2003, 03:20 AM #4Web Hosting Master
- Join Date
- Oct 2001
- Location
- California, USA
- Posts
- 1,316
Yes, fortunately our UseCanonicalName directive was aready 'On'.
And we do not compile Apache with mod_dav, does anyone actually use this module?http://www.voilaweb.com - the Social Internet Toolbox.