Results 1 to 17 of 17

Thread: phpSuExec?

  1. #1

    phpSuExec?

    I'm interested in hearing some opinions on why or why not run phpSuExec.

    Thank you.

  2. #2
    Join Date
    Jun 2002
    Location
    Orlando, FL
    Posts
    1,070
    You should definitely run phpsuexec, it is one of the smartest things you can do. If you are suffering from spam outbreaks and bot attacks and you enable phpsuexec: 95% of your issues will disappear.

    Searching Google for phpsuexec reveals a very good article found here:

    http://www.hostmagik.info/phpsuexec.php

    You may want to read over it a few times to fully grasp the concept. The only aspect that you may find discomforting is the .htaccess vs. php.ini issue. Other than that, many users may not even notice that phpsuexec is running on your server. Only those that have many PHP applications will come across unique issues that may require a little research at first, but in the end isn't security of the server most important?

  3. #3

  4. #4
    Join Date
    Aug 2004
    Location
    Earth
    Posts
    8,154
    phpsuexec is resource intensive.

  5. #5
    Join Date
    Oct 2006
    Location
    uk
    Posts
    448
    the only thing that concerns me about phpsuexec is that is that it means web servicing processs run as root then change privs, as opposed to starting unprivleged. am i worrying bout nothing?

  6. #6
    Join Date
    Oct 2006
    Location
    UK
    Posts
    217
    Go for mod_suphp rather than phpsuexec.

  7. #7
    Join Date
    Dec 2005
    Location
    Internet
    Posts
    1,352
    Quote Originally Posted by WN-Ali
    phpsuexec is resource intensive.

    Yeah, but its one of the greatest methods for ensuring server security.

  8. #8
    It doesn't use THAT many resources, unless you have like 1200 users on the server.
    Linux/BSD Systems Administrator

  9. #9
    Join Date
    Dec 2002
    Location
    chica go go
    Posts
    11,876
    Quote Originally Posted by linuxcares
    Yeah, but its one of the greatest methods for ensuring server security.
    Is it really?

    Under mod_php, the user has some control over what directories the web server has read/write/execute access to. Just change the last digit of the chmod string to whatever you want the web server to have access to.

    On phpsuexec, the web server will be able to read/write/execute to any directory that the owner has read/write/execute access to.

    Let's say your client forgets to update some software, and a phisher finds out, and takes advantage of the hole. On mod_php, the attacker would only be able to put their data to directories that are chmod 777, or whatever directory the public has write access to. On phpsuexec, the attacker would only be able to put his data in any directory, regardless of the public chmod string.

    I can see the benefits of phpsuexec, easier tracking of background processes, and email. But, to say that it is more secure just isn't true.

  10. #10
    Join Date
    Apr 2002
    Posts
    1,789
    Quote Originally Posted by ub3r
    Let's say your client forgets to update some software, and a phisher finds out, and takes advantage of the hole. On mod_php, the attacker would only be able to put their data to directories that are chmod 777, or whatever directory the public has write access to. On phpsuexec, the attacker would only be able to put his data in any directory, regardless of the public chmod string.
    By that same token, this can also have repercussions if mod_php is used.

    Consider a server that has two accounts. One account has a gallery script installed (or any script that requires PHP uploads to a directory). The user has to set permissions on the upload directory to 777, meaning that really anyone with access to the server could write files to that directory. The second account is running an outdated script, phpBB for example. Outside malicious users can exploit this outdated software on the second account, and upload files to the first account, perhaps for spamming. Then access those uploaded malicious files from the first account. How is this fair to the first account? Their script was not exploited, was not vulnerable, it is only because the second account was unwilling to keep their script up-to-date, and that caused their account to be targetted.

    If phpsuexec or suphp had been used, then you are correct in that a directory would not have to be set to 777 in order for malicious users to exploit this. But the malicious users would only be able to write files onto the second account, which had outdated software to begin with.

    To be a little blunt, if a user is not willing, for whatever reason, to keep their software up-to-date, then they have this coming to them. To go a little bit off topic here, I think the real problem is that a simplified method of updating scripts needs to be done. I think users are unwilling to keep their scripts up-to-date, because the task is too difficult for most users. But this doesn't mean that you can go around not keeping script up-to-date, because an outdated script is just asking for attack and problems.

  11. #11
    Join Date
    Jun 2002
    Location
    Orlando, FL
    Posts
    1,070
    Quote Originally Posted by Blackknight
    It doesn't use THAT many resources, unless you have like 1200 users on the server.
    True, we don't have any issues with it. It's not anything to worry about, just use it.
    | Manny Vivar - manny.v@hostdime.com| HostDime | Premier Global Data Centers
    | www.hostdime.com/global | Global Infrastructure as a Service (IaaS) Provider Since 2003
    | Managed Dedicated Servers | Global Colocation Facilities | Managed VPS | Managed Private Cloud
    | Data Centers in Florida, USA | Mexico | Brazil | UK | Hong Kong | India | Netherlands
    | Colombia |

  12. #12
    Join Date
    Jun 2002
    Location
    Orlando, FL
    Posts
    1,070
    Quote Originally Posted by carlgm
    Go for mod_suphp rather than phpsuexec.
    Why exactly? Phpsuexec is a stable and mature (rather than considering it EOL) codebase.
    | Manny Vivar - manny.v@hostdime.com| HostDime | Premier Global Data Centers
    | www.hostdime.com/global | Global Infrastructure as a Service (IaaS) Provider Since 2003
    | Managed Dedicated Servers | Global Colocation Facilities | Managed VPS | Managed Private Cloud
    | Data Centers in Florida, USA | Mexico | Brazil | UK | Hong Kong | India | Netherlands
    | Colombia |

  13. #13
    Join Date
    Dec 2002
    Location
    chica go go
    Posts
    11,876
    Consider a server that has two accounts. One account has a gallery script installed (or any script that requires PHP uploads to a directory). The user has to set permissions on the upload directory to 777, meaning that really anyone with access to the server could write files to that directory. The second account is running an outdated script, phpBB for example. Outside malicious users can exploit this outdated software on the second account, and upload files to the first account, perhaps for spamming. Then access those uploaded malicious files from the first account. How is this fair to the first account? Their script was not exploited, was not vulnerable, it is only because the second account was unwilling to keep their script up-to-date, and that caused their account to be targetted.
    Very good point, but couldn't this be prevented by open_basedir restrictions?

  14. #14
    Join Date
    Apr 2002
    Posts
    1,789
    If you have certain PHP functions disabled, then I suppose this could be less of an issue. You should definitely have open_basedir enabled if you are running mod_php, but I really would not expect it to stop every type of attack. I think a lot of emphasis is put on open_basedir protection, which I don't think it should be counted on.

    I guess the main point I'm trying to make in regards to this, is that open_basedir is inherent to PHP, which is the same system you are trying to protect. A bug or method outside of PHP would allow someone to circumvent open_basedir protection and exploit the PHP script. If you are running PHP as CGI (phpsuexec or suphp) then you more or less hand this type of security over to the filesystem and kernel. In an environment that is running PHP as CGI, then there is no need for so called open directories to exist on any account (directories that have permissions of 777) and because there is no common user interacting with between the accounts (i.e the nobody user or the apache user) then this automatically restricts access, without open_basedir.

    To answer your question if open_basedir would prevent that particular scenario, it might, and it would likely stop a lot of simple attacks, but I also believe it would be possible to get around it, unless other security measures are put in place.

  15. #15
    open_basedir will limit the damage, but in the end, there are easy ways to get around it. Best is to run PHP under suexec. Remember to run other CGI stuff (Perl, Python, Ruby, etc..) under suexec as well if you do run PHP under suexec, or you'll just be opening up a big hole to your server.

  16. #16
    Join Date
    May 2003
    Posts
    1,708
    It is about a 10-20% performance loss using phpsuexec. If you secure your server properly then it is completely obsolete to use this product as it does cause more problems than solving. Do some searches around here from some of the security guys and you will see more on that issue. phpsuexec provides a VERY false sense of security.
    ~~~~~~~~~~~~~~~~~~~~~
    UrNode - Virtual Solutions
    http://www.UrNode.com

  17. #17
    You can't properly secure your server (without suexec) against the shared user security problem because the flaw is in the design of the webserver and not PHP itself. This is why Apache developed the suexec workaround and suphpexec is merely an extension to the suexec workaround. You can basically say that suexec is part of "properly" securing the server but as mentioned, it will cause lots of problems due to its super strict file permission checks and lack of .htaccess support for php. Also, just installing phpsuexec doesn't automatically make your server more secure. You forget to suexec all your other CGI scripts (Perl, Python, Ruby, etc..) and you will have a even bigger security problem than before.

    For performance, you may want to look into PHP/FastCGI if you go the suexec route.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •