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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ