bugtraq - Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

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]

Message-ID: <Pine.LNX.4.44.0402050155330.999-100000@brama.integrate.com.ru>
Date: Thu, 5 Feb 2004 02:55:41 +0300 (MSK)
From: Dan Yefimov <dan@...egrate.com.ru>
To: André Malo <nd@...lig.de>
Cc: bugtraq@...urityfocus.com, <security@...pd.apache.org>
Subject: Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)


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

> * 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.
> 
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.