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 21:41:06 -0800
From: Seth Arnold <sarnold@...ex.com>
To: bugtraq@...urityfocus.com
Subject: Re: BUG IN APACHE HTTPD SERVER (current version 2.0.47)

On Thu, Feb 05, 2004 at 02:55:41AM +0300, Dan Yefimov wrote:
> 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.

Dan, do you have any suggestions how portions of a process should 'hide'
file handles from other portions of its own address space? [1]

Please remember that mod_perl, mod_python, mod_php, etc., were all written
to run scripts inside the address space of apache to help speed execution,
by removing the fork()/exec() slowdown required to provide a standard
privilege barrier. This speed comes at a cost that is acceptable for
some users and is unacceptable for other users.

Consider, without loss of generality, a server being used to host
amazon.com. Amazon could run their perl scripts in mod_perl; as the
only user of the system (and presumably they have internal controls
to ensure malicious code does not run on their webservers) this is an
appropriate choice.

Consider a website hosting provider, such as your favourite commercial
ISP. They can NOT trust their mutually distrusting users to run code
in their webserver's address space -- so, they cannot run mod_perl,
mod_python, mod_php, etc.

Presumably, the hosting providers can simply buy twice as many machines
and slightly raise their prices to their customers.

Whether to use mod_perl, mod_python, mod_php, etc., is strictly a
per-site decision that every administrator has to make for him or
herself, based on that site's security policy.

Thanks


[1] I'll note that Immunix's Secured Linux Distribution provides exactly
such a mechanism, in the form of "change_hat Apache", a patch to our
Apache package that makes a system call specific to Immunix's SubDomain
mandatory access control mechanism. While this is great for us, it
certainly isn't portable to all the platforms that Apache may run on.

-- 
Immunix Secured Linux Distribution: http://immunix.org/

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ