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

[langtuhaohoa caothuvolam <trungonly () yahoo com>]

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 .htaccess 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 think 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