BUG IN APACHE HTTPD SERVER (current version 2.0.47)

[Vietnamese Security Group]

APACHE HTTPD SERVER (current version 2.0.47):
################################################## ########
How to return files in a Apache Deny All directory.
The Directives controlling host access may be bypassed even
if they have not permission to be override.

11 Jan 2004


DESCRIPTION

Apache Web Server allows manage configurations via the main
httpd.conf file, and via the other configuration files placed
inside the children web trees, may owned by the user accounts,
named .htaccess by default. The server administrator further
controls what Directives may be placed in .htaccess files by
configuring the AllowOverride Directive in the main httpd.conf
files.

If the server admin sets the Deny Directive to All (for example),
and does not allow the user accounts to modify this Directive in
their .htaccess file by setting the AllowOverride values without
the Limit type, his/her users are still able to bypass the Deny
option by using the ErrorDocument Directive.

Tested in Apache 2.0.47/RH-Linux/WinXP.


EXAMPLE

################################################## ########
# In the main httpd.conf file:
#
<Directory />
AllowOverride FileInfo
Deny From All
</Directory>
################################################## ########

################################################## ########
# In the user's .htaccess file placed in a child directory:

ErrorDocument 403 /child/dir/fetch.php

################################################## ########

/************************************************** ******/
<?php
// In the fetch.php placed in the same directory:

$url = parse_url( $_SERVER['REQUEST_URI'] );
@include basename( $url['path'] );

?>
/************************************************** ******/


In this example, assuming the web server can execute PHP script
or some scripts/server-includes. By modifying some codes you can
return other mime file types such as image/gif etc.

Event if the server does not allow any file parsed (Deny From All),
the script file fetch.php will still be executed, and it includes
again and parses any other files in a same directory, which
indecated by the query variables, to the web client.

Looking in the source code, I think the missing auth checking is in
the function ap_process_request_internal() in the file request.c.
One of the major changes in Apache 2.0 is to the internal redirect
mechanism. To prevent the code from falling out of sync again in the
current directory, the configuration comparing between two config
directories may bypass the authentication checking again. That
explains why this vulnerability (if any?) can only done if the
redirect ErrorDocument file is placed in the same request directory.



FIX

Do not skip auth checker even if the per_dir_config member value
doesn't change in the ap_process_request_internal() function.


NOTE

I post this issue in the public mailing list, because I think this
vuln is not exploitable by a remote attacker. If something were
wrong, drop a line to me.


Vietnamese Security Group
Trung - caothuvolam - trungonly@yahoo.com
http://www.security.com.vn

31 Nui Truc st. Ba Dinh dist. Ha Noi . Vietnamese
Phone : 84.4.8465701 / Fax: 84.4.8465701

[Vietnamese Security Group]

In-Reply-To: <20040131211851.30391.qmail@www.securityfocus.com>

Note : of course it affected also in the current version 2.0.48 ( tested)

Vietnamese Security Group
www.security.com.vn


>Received: (qmail 2149 invoked from network); 3 Feb 2004 02:12:35 -0000
>Received: from outgoing3.securityfocus.com (205.206.231.27)
> by mail.securityfocus.com with SMTP; 3 Feb 2004 02:12:35 -0000
>Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
> by outgoing3.securityfocus.com (Postfix) with QMQP
> id 9667FA3153; Mon, 2 Feb 2004 18:23:17 -0700 (MST)
>Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>Received: (qmail 31275 invoked from network); 31 Jan 2004 21:08:29 -0000
>Date: 31 Jan 2004 21:18:51 -0000
>Message-ID: <20040131211851.30391.qmail@www.securityfocus.com>
>Content-Type: text/plain
>Content-Disposition: inline
>Content-Transfer-Encoding: binary
>MIME-Version: 1.0
>X-Mailer: MIME-tools 5.411 (Entity 5.404)
>From: Vietnamese Security Group <security@security.com.vn>
>To: bugtraq@securityfocus.com
>Subject: BUG IN APACHE HTTPD SERVER (current version 2.0.47)
>
>
>
>APACHE HTTPD SERVER (current version 2.0.47):
>################################################## ########
>How to return files in a Apache Deny All directory.
>The Directives controlling host access may be bypassed even
>if they have not permission to be override.
>
>11 Jan 2004
>
>
>DESCRIPTION
>
>Apache Web Server allows manage configurations via the main
>httpd.conf file, and via the other configuration files placed
>inside the children web trees, may owned by the user accounts,
>named .htaccess by default. The server administrator further
>controls what Directives may be placed in .htaccess files by
>configuring the AllowOverride Directive in the main httpd.conf
>files.
>
>If the server admin sets the Deny Directive to All (for example),
>and does not allow the user accounts to modify this Directive in
>their .htaccess file by setting the AllowOverride values without
>the Limit type, his/her users are still able to bypass the Deny
>option by using the ErrorDocument Directive.
>
>Tested in Apache 2.0.47/RH-Linux/WinXP.
>
>
>EXAMPLE
>
>################################################## ########
># In the main httpd.conf file:
>#
><Directory />
> AllowOverride FileInfo
> Deny From All
></Directory>
>################################################## ########
>
>################################################## ########
># In the user's .htaccess file placed in a child directory:
>
>ErrorDocument 403 /child/dir/fetch.php
>
>################################################## ########
>
>/************************************************** ******/
><?php
>// In the fetch.php placed in the same directory:
>
>$url = parse_url( $_SERVER['REQUEST_URI'] );
>@include basename( $url['path'] );
>
>?>
>/************************************************** ******/
>
>
>In this example, assuming the web server can execute PHP script
>or some scripts/server-includes. By modifying some codes you can
>return other mime file types such as image/gif etc.
>
>Event if the server does not allow any file parsed (Deny From All),
>the script file fetch.php will still be executed, and it includes
>again and parses any other files in a same directory, which
>indecated by the query variables, to the web client.
>
>Looking in the source code, I think the missing auth checking is in
>the function ap_process_request_internal() in the file request.c.
>One of the major changes in Apache 2.0 is to the internal redirect
>mechanism. To prevent the code from falling out of sync again in the
>current directory, the configuration comparing between two config
>directories may bypass the authentication checking again. That
>explains why this vulnerability (if any?) can only done if the
>redirect ErrorDocument file is placed in the same request directory.
>
>
>
>FIX
>
>Do not skip auth checker even if the per_dir_config member value
>doesn't change in the ap_process_request_internal() function.
>
>
>NOTE
>
>I post this issue in the public mailing list, because I think this
>vuln is not exploitable by a remote attacker. If something were
>wrong, drop a line to me.
>
>
>Vietnamese Security Group
>Trung - caothuvolam - trungonly@yahoo.com
>http://www.security.com.vn
>
>31 Nui Truc st. Ba Dinh dist. Ha Noi . Vietnamese
>Phone : 84.4.8465701 / Fax: 84.4.8465701
>

[=?ISO-8859-15?Q?Andr=E9?= Malo]

* Vietnamese Security Group <security@security.com.vn> wrote:

[snakeoil]

> Event if the server does not allow any file parsed (Deny From All),
> the script file fetch.php will still be executed, and it includes
> again and parses any other files in a same directory, which
> indecated by the query variables, to the web client.

Deny from all (in conclusion with some other) denies HTTP access on some
criteria. It doesn't suppose to protect against access from inside the
server.


> I post this issue in the public mailing list, because I think this
> vuln is not exploitable by a remote attacker. If something were
> wrong, drop a line to me.

Next time, try a user support forum first. Thanks.

nd

[=?ISO-8859-15?Q?Andr=E9?= Malo]

* langtuhaohoa caothuvolam <trungonly@yahoo.com> wrote:

> Deny From All: In this way they can access from outside the server.

You mean: An attacker needs to place such a script on the server, which
includes the requested uri.
If he's able to do so, he can

(a) read the file anyway
(b) simply open it from inside the script using normal file operations.

I cannot see a vuln here. If he's able to take the actions described above,
one has *real* trouble on the server.

This seems to me the same topic as the mod_perl hijacking. If you don't trust
your users, don't let them execute code from inside the server.

nd

[langtuhaohoa caothuvolam]

In-Reply-To: <20040203063933.12546429.nd@perlig.de>

>From: =?ISO-8859-15?Q?Andr=E9?= Malo <nd@perlig.de>
>
>
>Deny from all (in conclusion with some other) denies HTTP access on some
>criteria. It doesn't suppose to protect against access from inside the
>server.
>

Deny From All: In this way they can access from outside the server.
AllowOverride FileInfo (only): Apache must suppose to protect against .htaccess override from inside the server.
In fact, Apache should check for config permission again in the ap_process_request_internal() function.


>
>> I post this issue in the public mailing list, because I think this
>> vuln is not exploitable by a remote attacker. If something were
>> wrong, drop a line to me.
>
>Next time, try a user support forum first. Thanks.
>
>nd
>
I think it's a vuln, in fact I confirmed someones for that. Then I post it into a bug-tracker list instead of in a user support forum. Thanks for your comment.

[Dan Yefimov]

On Wed, 4 Feb 2004, [ISO-8859-15] André Malo wrote:

> * langtuhaohoa caothuvolam <trungonly@yahoo.com> wrote:
>
> > Deny From All: In this way they can access from outside the server.
>
> You mean: An attacker needs to place such a script on the server, which
> includes the requested uri.
> If he's able to do so, he can
>
> (a) read the file anyway
> (b) simply open it from inside the script using normal file operations.
>
> I cannot see a vuln here. If he's able to take the actions described above,
> one has *real* trouble on the server.
>
> This seems to me the same topic as the mod_perl hijacking. If you don't trust
> your users, don't let them execute code from inside the server.
>
The matter here is not the trust. The matter is that restrictions inflicted by
server admin shouldn't be able to be avoided by using, for example, the
described trick. This is of course not a vuln, but this is a design flaw that
can have some security implications and should be fixed anyway.
As for mod_perl hijacking. Mod_perl has been designed only to speed up
perl CGI scripts execution unrelated to whether server admin trusts his/her
users or not (and mod_php serves the like objective). Thus under mod_perl
control scripts should be run in the same environment as if they were run in a
common way (by forking, closing all file handles except for connected socket and
executing perl interpreter). This means mod_perl must somehow hide all those
file handles from the script being executed. If mod_perl doesn't do that, it's
not simply a design flaw, but it's also a serious security flaw.
--

Sincerely Your, Dan.

[Seth Arnold]

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 05, 2004 at 02:55:41AM +0300, Dan Yefimov wrote:
> This means mod_perl must somehow hide all those file handles from the
> script being executed. If mod_perl doesn't do that, it's not simply a
> design flaw, but it's also a serious security flaw.

Dan, do you have any suggestions how portions of a process should 'hide'
file handles from other portions of its own address space? [1]

Please remember that mod_perl, mod_python, mod_php, etc., were all written
to run scripts inside the address space of apache to help speed execution,
by removing the fork()/exec() slowdown required to provide a standard
privilege barrier. This speed comes at a cost that is acceptable for
some users and is unacceptable for other users.

Consider, without loss of generality, a server being used to host
amazon.com. Amazon could run their perl scripts in mod_perl; as the
only user of the system (and presumably they have internal controls
to ensure malicious code does not run on their webservers) this is an
appropriate choice.

Consider a website hosting provider, such as your favourite commercial
ISP. They can NOT trust their mutually distrusting users to run code
in their webserver's address space -- so, they cannot run mod_perl,
mod_python, mod_php, etc.

Presumably, the hosting providers can simply buy twice as many machines
and slightly raise their prices to their customers.

Whether to use mod_perl, mod_python, mod_php, etc., is strictly a
per-site decision that every administrator has to make for him or
herself, based on that site's security policy.

Thanks


[1] I'll note that Immunix's Secured Linux Distribution provides exactly
such a mechanism, in the form of "change_hat Apache", a patch to our
Apache package that makes a system call specific to Immunix's SubDomain
mandatory access control mechanism. While this is great for us, it
certainly isn't portable to all the platforms that Apache may run on.

--=20
Immunix Secured Linux Distribution: http://immunix.org/

--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAIyjy+9nuM9mwoJkRAnRSAJ0R4/XricudnOpl7mH9n528QmgIPACeN5eS
1rhC5yNNICLcaq7aDh4PWjI=
=PfVr
-----END PGP SIGNATURE-----

--r5Pyd7+fXNt84Ff3--

[Tyler Larson]

I can see how this could *possibly* be an issue.

In theory, a user on a shared system could use an ErrorDocument directive to
view file that the apache user/group had access to, but the user didn't (such
as another user's .htaccess file. The directive would look something like this:

ErrorDocument 404 /~otheruser/.htaccess

However, in my version of apache (2.0.48) it doesn't work:

Given a the set of files below:

-- /www/foo/.htaccess --
[see below] (no other files in this directory)
-- EOF --

-- /www/foo/bar/.htaccess --
Order Deny, Allow
Deny from all
-- EOF --

-- /www/foo/bar/secret --
you saw my secret!
-- EOF --

And I tried the following values in in /www/foo/.htaccess

----
ErrorDocument 404 /foo/bar/secret
----
ErrorDocument 404 /foo/.htaccess
----
#I knew this one had no chance
ErrorDocument 404 /etc/passwd
----

For the first two .htaccess files, I got this response:
-----------
Not Found
The requested URL /foo/baz was not found on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an
ErrorDocument to handle the request.
Apache/2.0.48 (Fedora) Server at localhost Port 80
-----------

For the last .htaccess file, I got this response:
-----------
Not Found
The requested URL /foo/baz was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an
ErrorDocument to handle the request.
Apache/2.0.48 (Fedora) Server at localhost Port 80
-----------

The reason why the last one didn't work was because ErrorDocument files are
relative to the server's DocumentRoot, not the filesystem root.

The first request didn't work because of my "Deny From All" in
foo/bar/.htacess, while the second request failed because of the restrictions
placed by default on files starting with ".ht".

[Todd C. Campbell]

On Thu, Feb 05, 2004 at 02:55:41AM +0300, Dan Yefimov wrote:
> On Wed, 4 Feb 2004, [ISO-8859-15] Andr? Malo wrote:
> The matter here is not the trust. The matter is that restrictions inflicted by
> server admin shouldn't be able to be avoided by using, for example, the
> described trick. This is of course not a vuln, but this is a design flaw that
> can have some security implications and should be fixed anyway.
> As for mod_perl hijacking. Mod_perl has been designed only to speed up
> perl CGI scripts execution unrelated to whether server admin trusts his/her
> users or not (and mod_php serves the like objective). Thus under mod_perl
> control scripts should be run in the same environment as if they were run in a
> common way (by forking, closing all file handles except for connected socket and
> executing perl interpreter). This means mod_perl must somehow hide all those
> file handles from the script being executed. If mod_perl doesn't do that, it's
> not simply a design flaw, but it's also a serious security flaw.


I do not believe this is a function of the web server. For example any
per script can read in a file that is not contained within the document
root, as so long as the process has sufficient priviledges to read the
file. Any files that you do not want to be read by the web
server should be permissioned as such.

You argue that the server admin should be able to set restrictions to
the server. Here I agree, however, that restrictive mechanism lies
within the filesystem permissions and is not a function of the
webserver. When it comes down to it, you are trying to restrict read
access for the files in question, why would it be any different than
restricting read access for any other user on the system?

.tidd.