Re: BUG IN APACHE HTTPD SERVER 2.0.47/48 (to who replied me)

[William A. Rowe, Jr.]

Finally the gist of a very effective question:

Q. Should Apache require that the .htaccess-permitted web content=20
allow the user to control the ErrorDocument directive?

A. Yes, provided that AllowOverride FileInfo (or AllowOverride All) is given
in the httpd.conf file for the web content's directory tree.

http://httpd.apache.org/docs-2.0/mod/core.html#allowoverride

"FileInfo
Allow use of the directives controlling document types (...)"

Any administrator who would permit untrusted content authors to use the
..htaccess file in such an open manner would be foolish. The examples
you are citing imply that the Administrator is taking steps to lock down
the server. The very FIRST thing such an administrator would do would
be to restrict AllowOverride and ensure Options FollowSymLinks is off.

I validated this behavior in httpd-2.0 and apache-1.3 - and in both cases
the ErrorDocument directive is restricted to AllowOverride FileInfo.

The report is based on the assumption that the administrator went to only
half the effort to lock down the server, therefore it's certainly not a bug
or hole in the Apache server, but in the configuration you've proposed.

Yours,

Bill

At 03:58 AM 2/5/2004, Phan "Th=E1i" Trung wrote:

>Hi Reagan Blundell, Andre Malo, Rafael D'Avila...
>
>Thanks for your comment. But let's think a bit more carefully and reply to=
me your opnion.=20
>
>Suppose that the root *user set* a directory to Deny From All, so in fact=
all web users should not be able to get its content. But a *reseller user*=
who has the right to modify the .htaccess file (ErrorDocument), could let=
other *web users* get its content via a 403 document, or at least get the=
403 doc itself, which is placed in the same directory. In this case, we do=
not need PHP.=20
>
>Answer me, it's a Apache feature, or a mistake of Apache?=20
>
>Best Regards,=20
>
>Trung
>
>=20
>
>
>Reagan Blundell <Reagan.Blundell@Centradia.com> wrote:=20
>>=20
>> I think it's a vuln, in fact I confirmed someones for that.=20
>> Then I post it into a bug-tracker list instead of in a user=20
>> support forum. Thanks for your comment.
>>=20
>
>The only reason it is a "vulnerability", is because PHP allows a user to
>read files from the system. This is completely regardless of whatever
>protections you have set up in Apache. If you don't trust your users, then
>allowing them to run PHP scripts is just plain stupid. This is not a
>security issue with apache. This is an administrator not knowing the
>consequences of giving users access to PHP.
>
>
>
>Rafael D'Avila <rooter@terra.com.br> wrote:=20
>IMHO, there's no vulnerability here... if you trust your users, and let=
them
>execute some codes from inside the server, you are only using a feature of
>Apache, and have to be the responsibility if someone execute dangerous
>codes....
>
>Only my 0.2 cents
>
>Rafael D'=C1vila
>(core_dumped@terra.com.br)
>
>----- Original Message -----=20
>From: "Andr=E9 Malo"=20
>To: "langtuhaohoa caothuvolam"=20
>Cc: ;=20
>Sent: Wednesday, February 04, 2004 4:07 PM
>Subject: Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)
>
>
>> * langtuhaohoa caothuvolam 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
>>
>
>
>Do you Yahoo!?
>Yahoo! Finance:=
<http://us.rd.yahoo.com/evt=3D22055/*http://taxes.yahoo.com/filing.html>Get=
your refund fast by filing online=20

[langtuhaohoa caothuvolam]

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

Hi Reagan Blundell, Andre Malo, Rafael D'Avila...

Thanks for your comment. But let's think a bit more carefully and reply to me your opnion.

Suppose that the *root user* set a directory to Deny From All, so in fact all web users should not be able to get its content. And of course, the *root user* don't trust any one except himself :) But a *reseller user* who has the right to modify the .htac
cess file (ErrorDocument only), could let other *web users* get its content via a 403 document, or at least get the 403 doc itself, which is placed in the same directory. In this case, we do not need PHP.

===> Answer me, it's a Apache feature, or a mistake of Apache?

In fact, in the function ap_process_request_internal() (v.2.0.47/48), the coder commented:

/* Skip authn/authz if the parent or prior request passed the authn/authz,
* and that configuration didn't change (this requires optimized _walk()
* functions in map_to_storage that use the same merge results given
* identical input.) If the config changes, we must re-auth.
*/

I think the mistaken is in here: They skiped auth check in the second checking step in the same dir, so the content of 403 doc or any later doc have been still parsed, even if this dir is Deny From All. I don't think forever it's an Apache feature, I thin
k the coder should re-auth again here.

Best Regards,

Trung



>From: =?ISO-8859-15?Q?Andr=E9?= Malo <nd@perlig.de>
>To: langtuhaohoa caothuvolam <trungonly@yahoo.com>
>Cc: bugtraq@securityfocus.com, security@httpd.apache.org
>Subject: Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)
>
>* 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
>

[Phan Thái Trung]

Hi William A. Rowe,

In my article, I supposed that the administrator
permit AllowOverride FileInfo, and you, supposed that
the admin restrict that. What happens if he permit
AllowOverride FileInfo?

The problem is, when I tested and looked at the source
code, if the 403 or other Error document placed
somewhere outside this current directory, it is not
parsed in the Deny From All URL (normally, Apache
wants). If the 403 doc placed in the current
directory, it can be parsed (unnormally, Apache may
not want).

We don't want to prevent this by going round,
re-configuring Apache in the other way, but by
ensuring that Apache works well in both cases, the 403
doc placed outside or inside the restricted directory.

Trung




--- "William A. Rowe, Jr." <wrowe@rowe-clan.net>
wrote:
> Finally the gist of a very effective question:
>
> Q. Should Apache require that the
> .htaccess-permitted web content
> allow the user to control the ErrorDocument
> directive?
>
> A. Yes, provided that AllowOverride FileInfo (or
> AllowOverride All) is given
> in the httpd.conf file for the web content's
> directory tree.
>
>
http://httpd.apache.org/docs-2.0/mod/core.html#allowoverride
>
> "FileInfo
> Allow use of the directives controlling document
> types (...)"
>
> Any administrator who would permit untrusted content
> authors to use the
> .htaccess file in such an open manner would be
> foolish. The examples
> you are citing imply that the Administrator is
> taking steps to lock down
> the server. The very FIRST thing such an
> administrator would do would
> be to restrict AllowOverride and ensure Options
> FollowSymLinks is off.
>
> I validated this behavior in httpd-2.0 and
> apache-1.3 - and in both cases
> the ErrorDocument directive is restricted to
> AllowOverride FileInfo.
>
> The report is based on the assumption that the
> administrator went to only
> half the effort to lock down the server, therefore
> it's certainly not a bug
> or hole in the Apache server, but in the
> configuration you've proposed.
>
> Yours,
>
> Bill
>
> At 03:58 AM 2/5/2004, Phan "Thái" Trung wrote:
>
> >Hi Reagan Blundell, Andre Malo, Rafael D'Avila...
> >
> >Thanks for your comment. But let's think a bit more
> carefully and reply to me your opnion.
> >
> >Suppose that the root *user set* a directory to
> Deny From All, so in fact all web users should not
> be able to get its content. But a *reseller user*
> who has the right to modify the .htaccess file
> (ErrorDocument), could let other *web users* get its
> content via a 403 document, or at least get the 403
> doc itself, which is placed in the same directory.
> In this case, we do not need PHP.
> >
> >Answer me, it's a Apache feature, or a mistake of
> Apache?
> >
> >Best Regards,
> >
> >Trung
> >
> >
> >
> >
> >Reagan Blundell <Reagan.Blundell@Centradia.com>
> wrote:
> >>
> >> 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.
> >>
> >
> >The only reason it is a "vulnerability", is because
> PHP allows a user to
> >read files from the system. This is completely
> regardless of whatever
> >protections you have set up in Apache. If you don't
> trust your users, then
> >allowing them to run PHP scripts is just plain
> stupid. This is not a
> >security issue with apache. This is an
> administrator not knowing the
> >consequences of giving users access to PHP.
> >
> >
> >
> >Rafael D'Avila <rooter@terra.com.br> wrote:
> >IMHO, there's no vulnerability here... if you trust
> your users, and let them
> >execute some codes from inside the server, you are
> only using a feature of
> >Apache, and have to be the responsibility if
> someone execute dangerous
> >codes....
> >
> >Only my 0.2 cents
> >
> >Rafael D'Ávila
> >(core_dumped@terra.com.br)
> >
> >----- Original Message -----
> >From: "André Malo"
> >To: "langtuhaohoa caothuvolam"
> >Cc: ;
> >Sent: Wednesday, February 04, 2004 4:07 PM
> >Subject: Re: BUG IN APACHE HTTPD SERVER (current
> version 2.0.47)
> >
> >
> >> * langtuhaohoa caothuvolam 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
> >>
> >


__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

[Guille -bisho-]

> In my article, I supposed that the administrator
> permit AllowOverride FileInfo, and you, supposed that
> the admin restrict that. What happens if he permit
> AllowOverride FileInfo?
>=20
> The problem is, when I tested and looked at the source
> code, if the 403 or other Error document placed
> somewhere outside this current directory, it is not
> parsed in the Deny From All URL (normally, Apache
> wants). If the 403 doc placed in the current
> directory, it can be parsed (unnormally, Apache may
> not want).
>=20
> We don't want to prevent this by going round,
> re-configuring Apache in the other way, but by
> ensuring that Apache works well in both cases, the 403
> doc placed outside or inside the restricted directory.

Imagine one of the resellers want to forbit access to all his directory,
and he want's also to put an special error document. There is no reason
why he should add an special allow to the error file.

If the apache admin wants to disallow access of a reseller directory, he
*MUST* disable overrive also. If he doesn't, the user will still be able
to execute php files with error document. Not in that directory but
perfectly in others, imagine /tmp or something similar.

Maybe a warning could be added to the Deny rule in apache documentation,
indicating that this will not prevent access to files from errordocument
directives or other scripting languages (as PHP) that do not follow
apache deny rules.

--=20
_ Guillermo P=E9rez -=3D] 09/02/2004 [=3D-
<=B7) - bisho@ ( onirica.com | eurielec.etsit.upm.es )
( \>
bisho! ""\\ :: Say NO!!! to SW PATENTS ::
..........:: EuropeSwPatentFree: ::
:: http://europeswpatentfree.hispalinux.es/ ::