lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20040205102210.11848.qmail@www.securityfocus.com>
Date: 5 Feb 2004 10:22:10 -0000
From: langtuhaohoa caothuvolam <trungonly@...oo.com>
To: bugtraq@...urityfocus.com
Subject: Re: BUG IN APACHE HTTPD SERVER 2.0.47/48 (to who replied me)


In-Reply-To: <20040204190737.7cbb8939.nd@...lig.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@...lig.de>
>To: langtuhaohoa caothuvolam <trungonly@...oo.com>
>Cc: bugtraq@...urityfocus.com, security@...pd.apache.org
>Subject: Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)
>
>* langtuhaohoa caothuvolam <trungonly@...oo.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
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ