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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 5 Feb 2004 09:01:28 -0800 (PST)
From: Phan "Thái" Trung <trungonly@...oo.com>
To: "William A. Rowe, Jr." <wrowe@...e-clan.net>
Cc: Rafael D'Avila <rooter@...ra.com.br>,
	Reagan Blundell <Reagan.Blundell@...tradia.com>,
	"André_Malo" <nd@...lig.de>, bugtraq@...urityfocus.com,
	security@...pd.apache.org, trungonly@...oo.com
Subject: Re: BUG IN APACHE HTTPD SERVER 2.0.47/48 (to who replied me)


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@...e-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@...tradia.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@...ra.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@...ra.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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ