[thelist] PHP Perl Apache security

[Keith]

At 09:14 AM Sunday 7/20/2003, you wrote:

>should be aware of this. As a hosting provider, you might do well to make
>that clear, and use the opportunity to upsell them to dedicated (most hosts

Good point. Actually we are not the hosting company - we provide a server 
app for hosting companies and we are insisting on a secure environment. The 
host provider with 15,000 is the biggest, but overall we have over 50K 
domains to consider on god knows how many servers, with a half a dozen host 
providers - and counting. We were flabbergasted to find that 6 out of 9 
Apache hosting companies we've dealt with have the Perl/PHP vulnerability I 
described, and didn't know it. So far they all want to get hardened, so we 
are looking for the most painless way to do it - painless for the end-user 
and the hosts.

>true - but not prohibitively so. I use a certain undisclosed Vhost that uses
>this strategy, and while I have no idea what the hardware etc. is,
>performance is very good. and again, if you want great performance, you

Good point also. But we have no control over the hardware. The 15,000 
client host estimates they will need to move hundreds of domains off to new 
servers to guarantee the same per domain load that they now have if they 
switch from Apache module to CGI.

>     AddType  application/x-httpd-php .php
>     Action application/x-httpd-php /cgi-bin/php
>inside the <VirtualHost> section.

Ahhh... Yeah, I've seen that but I think I failed to connect the dots. I'll 
try it. Our biggest host is leaning toward the CGI method but that shebang 
line scares them because it requires the client to do something that many 
will balk at or botch. THANKS for pointing that out!!!

>the bonus advantage with this method: users can have their own php.ini 
>files -
>and their own version of php! Just complile php as CGI, point the
>configuration directive for the php.ini location to their working dir, put
>the binary in their cgi-bin... (well, ok, times 15,000...)

:-) right. I think we'll leave that call up to the hosting provider....

>So, I vote for this method. In fact, as a customer I prefer it too, as 
>long as
>the performance is ok. No more security problems, all files are owned by user

We'll see what the performance penalty is. PHP claims it's significant, but 
then they are more concerned with selling speed than security.

THANKS!!


Keith
====================
cache at dowebscentral.com