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: <20040206054106.GA21221@wirex.com>
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