Hi,

On a shared-server with PHP compiled as a module, we have a security problem, which is the user can write malicious code to either snoop around other customer's directory or hack the system since the script is being run as apache (nobody) instead of the customer own user id. SuEXEC only solves the PHP CGI, but not the PHP module. safe_mode or open_base_dir is not the ultimate solution too.

Recently I came across a site which the developer claims that the patch he developed solves this problem.

http://luxik.cdi.cz/~devik/apache/

Anyone ever came across this site? Or could any experts out there evaluate and test the code? If it claims what it can do and stable enough, I can't see why we shouldn't use this.

Later
Joe

I honestly think you'd be better off using Apache 2.x instead of this. Apache 2.x might be BETA, but it's being used in a lot of places and looks like it might finally be released soon. Even Apache.org runs 2.x.

Originally posted by Tim_Greer
I honestly think you'd be better off using Apache 2.x instead of this.

Do you have any personal experiences?
I think many are eagerly waiting for this release...

Originally posted by Walter


Do you have any personal experiences?
I think many are eagerly waiting for this release...

Hi, if you have any extra partition free, another drive or another system, or another server, you can pretty safely install it to test and use it for your needs. With the stuff I want and that most web servers need and use (i.e., common modules, configurations, etc. (i.e., CGI, PHP, SSL, etc.)), I haven't noted any problems with it. I haven't tried to use all the new features, some of which are things I don't want or care for (and a lot of it also is to make it better on Win32 systems, again, I don't care and I wish they's just do that in another version so we don't have to wait because of it), so it'll work pretty well. I'll not use it on a client server until I'm certain it's okay (and although people are using it now without problems, I want to be sure that everyone has given the code and whatnot the twice over - which Apache is encouraging people to do -- before it's finally released non-BETA soon). In other words, there's really no reason for people to not install and test it out, even if you have to make a new partition (*or a few) on your drive at home, and use it and see what you think.

Originally posted by joethong
...Recently I came across a site which the developer claims that the patch he developed solves this problem.

http://luxik.cdi.cz/~devik/apache/


That's funny. I just came across that yesterday, myself. I was going to review the code and see if it's worth even trying. I'll let you know what I find.

If nothing else, it may inspire me to find another fix.

My concern so far is the whole changing the owner of the apache child. There has to be a better way.

If you try it, I'd be happy to hear what you find.

Originally posted by joethong

Recently I came across a site which the developer claims that the patch he developed solves this problem.

http://luxik.cdi.cz/~devik/apache/

Anyone ever came across this site? Or could any experts out there evaluate and test the code? If it claims what it can do and stable enough, I can't see why we shouldn't use this.

Later
Joe


It is basically the same with mod_become (http://www.snert.com/Software/mod_become/index.shtml), but mod_become is cleaner and easier to install.

I don't like the idea of this, it defeats the purpose of apache module in the first place. Then, why don't use CGI mode php instead.

Hi,

Thanks for the help Mark, let me know if you find if its worth trying. I'm desperate in looking for something like this. I can't wait for Apache2 anymore

And as for mod_become, this is a funny statement

---
USE OF THIS MODULE MAY OPEN SECURITY EXPLOITS WITHIN APACHE AND ITS INSTALLED MODULES. THE AUTHOR DOES NOT RECOMMEND THE USE OF THIS MODULE. THE AUTHOR DOES NOT ACCEPT ANY RESPONSIBLITY FOR SECURITY BREACHES ON ANY WEB SERVER WHERE THIS MODULE IS EMPLOYED, NOR ANY SECURITY BREACHES ON THOSE COMPUTERS ACCESSIBLE FROM A WEB SERVER EMPLOYING THIS MODULE. USE AT YOUR OWN RISK.
---

Huh?! THE AUTHOR DOES NOT RECOMMEND THE USE OF THIS MODULE? Why did he create the thing in the first place then? Anyway, what kind of possible security exploits would there be.

We've also have mod_perl installed, anyone know how can we protect this too? Is there something similar to safe_mode in PHP?

Thanks for the help guys.
Joe

P.S: Priyadi, are you using PHP CGI right now? Is it reliable enough to install it on a server that supports 400 customers?

safe_mode or open_base_dir is not the ultimate solution too


joethong, sorry for getting a little bit off-topic here just curious to hear why?

Originally posted by priyadi

I don't like the idea of this, it defeats the purpose of apache module in the first place. Then, why don't use CGI mode php instead.

This might be a better solution than using PHP as CGI for the following reasons:

1) Resource sharing (presistant database connections, and php.ini is read only once when the server is initially started).

2) Transparency. There will be no need to chmod PHP files differently and there will be no need for the shebang line in top of PHP files.

I'm not sure about reason though (1); but I'm interested to know if, and how, are you achieving (2) in your current setup?

I've liked your idea of running PHP as CGI, but the problem is that you have to ask your clients to add the shebang line to the top of all their PHP scripts.

That would be OK by Python or Perl, because # in these languages denotes a comment, so if it is run using mod_perl or mod_snake, the shebang line will be ignored.

Thats not the case with PHP, because putting the shebang line at the top of a PHP script and running it using mod_php would leed to the shebang line appearing in the output of the script. This is because # will only comment lines out if yout enter PHP mode (between <?php and ?>).

The advantages of running PHP as CGI are:

- Users are protected from each other. When configured properly there's no way a user can sabotage any other user.

- It is easy to monitor resources. It is possible to monitor CPU and memory usage. Under Apache module this is impossible or very difficult. Eventually I will be able to monitor bandwidth usage from php scripts as well, like RDF downloads, SOAP, XMLRPC, etc. Those are getting more popular these days. With CGI mode, it is not possible to do that without doing major code whacking to PHP.

About shebang line, you can eliminate that requirement by using binfmt_misc under Linux (not sure if it's possible on other OS). The downside your users will not be able to define additional extensions to be recognized as PHP files.

You still need to chmod +x them though.

Originally posted by joethong
Hi,
Huh?! THE AUTHOR DOES NOT RECOMMEND THE USE OF THIS MODULE? Why did he create the thing in the first place then? Anyway, what kind of possible security exploits would there be.


Yeah :) basically the module changes the default security model used by apache. So it is a very dangerous module indeed. :)


We've also have mod_perl installed, anyone know how can we protect this too? Is there something similar to safe_mode in PHP?


No, I don't think so. I believe the only safe way to run mod_perl (or any mod_whatever for that matter) is to run one Apache for each user. Apache 2.0 is supposed to fix this problem I believe.


P.S: Priyadi, are you using PHP CGI right now? Is it reliable enough to install it on a server that supports 400 customers?

I have servers with more than 300 users in it. No sweat. :)

Originally posted by ASPCode.net
joethong, sorry for getting a little bit off-topic here just curious to hear why?

My take on safe_mode or open_base_dir, are that you are not allowing PHP itself to access any files that the owner of the php file can't. However, they can still execute external programs as the owner of mod_php. So then you have to use safe_mode_exec_dir and really limit them to not execute any external programs from within the PHP.

So what would be optimum is a complete user switch, like with suexec, but then like priyadi said, you might as well just start a seperate CGI process, because the only other option is to change the owner that the apache child runs as.

What would be optimum is to use PHP as a CGI environment, but to just have mod_php hide the fact that it's not being parsed by apache itself. But again, you'll really be running it in CGI mode, but it would be transparent to the users.

Although priyadi suggested that you can almost do this now, except for the executable permissions.