Results 1 to 14 of 14
  1. #1
    Join Date
    Jan 2006
    Posts
    264

    Is PHP in FastCGI mode & suPHP a security risk?

    I was talking to a friend of mine today that manages a couple of servers for a local company. I explained to him that I recently reconfigured my vps to use PHP in FastCGI mode with suPHP and he said that it was a major security issue.

    Can anyone give my their input??

  2. #2
    Join Date
    Aug 2007
    Posts
    53
    I personally prefer suPHP. If you are using suPHP, when a user unknowingly has an exploitable script, and causes the server to get compromised, you will be in a better situation.

    Now you know you are searching for files owned by that particular user, in directories (s)he can write to. Rather than trying to go through EVERY users webdata because everything is owned by user apache, or nobody.

    In some cases it even works in the other direction. By finding files in /tmp, owned by userA, we know userA is the one who got exploited... That makes digging through the logs much easier, because now its just logs for one domain, rather than all of them.

    In my opinion suPHP provides more damage control in an environment that none of us can control at every moment, all the time.

    Unless your friend provided any solid points, I think he was just talking out of his ***.

  3. #3
    Join Date
    Mar 2004
    Posts
    695
    maybe zincoxide means using suPHP and FastCGI, because suphp runs php files as cgi, using FastCGI would be a way to a way to speed them,but i'm unsure about the performance increase of adding FastCGI

  4. #4
    Join Date
    Jan 2006
    Posts
    264
    He did admit that he wasn't aware of the security risks involved (if any) by using FastCGI. He said that running PHP in CGI mode alone was a big risk but he didn't know about FastCGI.

    Then, when I told him that I am running suPHP and he said it was an even bigger risk.

  5. #5
    Join Date
    Jul 2002
    Location
    New York, USA
    Posts
    466
    Quote Originally Posted by zincoxide View Post
    He did admit that he wasn't aware of the security risks involved (if any) by using FastCGI. He said that running PHP in CGI mode alone was a big risk but he didn't know about FastCGI.

    Then, when I told him that I am running suPHP and he said it was an even bigger risk.
    To be honest, doesn't sound like they understand what's going on. suPHP a security risk?? suphp if setup properly INCREASES security. Each user runs as their own user/group and is sandboxed much better than standard mod_php.

    FastCGI is also an option if setup properly.
    Larry Ludwig
    Empowering Media
    HostCube - Proactively Managed Xen based VPSes
    Empowering Media - The Dev Null Blog

  6. #6
    Join Date
    Jan 2006
    Posts
    264
    I did set it up with FastCGI & suPHP. You mentioned "if setup properly".

    Would you mind taking a minute to let me know what things I should look for to make sure that I set it up correctly. I would like to verify that I did it properly.

  7. #7
    Join Date
    Jan 2006
    Location
    Sydney, Australia
    Posts
    251
    Quote Originally Posted by empoweri View Post
    To be honest, doesn't sound like they understand what's going on. suPHP a security risk?? suphp if setup properly INCREASES security. Each user runs as their own user/group and is sandboxed much better than standard mod_php.
    The problem I have with suPHP is, that the scripts run with the permission of the script owners, which can cause a lot more harm than mod_php or normal PHP/FastCGI where PHP runs with the permission of apache/nobody/www-data user.

    Yes I know they are better sandboxed -- each user can only shoot their own feet. However, if the script does get exploited (by allowing to write to an arbitrary file for example), they can basically rewrite every file and every directory you user owns (i.e. their entire home directory and public_html), without the need for them to chmod o+w. Whereas if the exploited script runs as nobody/www-data, the only writable area would be maybe /tmp, /var/tmp or directories explicitly had chmod 777.

  8. #8
    Join Date
    Feb 2008
    Location
    Austin, Texas
    Posts
    272
    But then they can also write in any directories owned by other users that have either incorrect permissions on them or are required to be writable by the web server (ie, the uploads or images directories for many CMS softwares). suPHP is a far better option... One account being destroyed is much better than a few dozen or even a few hundred. There are a lot of other things that can be done in php.ini and with suhosin to secure PHP installations... And there isn't any major problem that I know of running PHP under FastCGI, either. It's a commonly accepted (and secure) method of running multiple PHP versions.
    ██ HermeTek Network Solutions
    ██ Network design, security, and implementation
    ██ BSD & Linux consulting, training, and hosting
    ██ https://www.hermetek.com | 1.866.235.1288

  9. #9
    Join Date
    Jul 2002
    Location
    New York, USA
    Posts
    466
    Quote Originally Posted by ylsy View Post
    Yes I know they are better sandboxed -- each user can only shoot their own feet. However, if the script does get exploited (by allowing to write to an arbitrary file for example), they can basically rewrite every file and every directory you user owns (i.e. their entire home directory and public_html), without the need for them to chmod o+w. Whereas if the exploited script runs as nobody/www-data, the only writable area would be maybe /tmp, /var/tmp or directories explicitly had chmod 777.
    Yes that is true, take some good with bad. I see it as I would rather have one user infected instead of many. Many customers have chmod 777 or 666 on folders/files because either out of ignorance or because they need folders/files to be written by apache (with a mod_php setup). With suphp you don't have this issue and in fact can force 750 or 640 perms. user shoots their own foot and only their own foot.

    The other issue is you can quickly detect hacked accounts based upon processes running in memory. If they are running for awhile (ie 20 min) then more than likely not legit PHP processes.

    The other disadvantage to suPHP is performance. As an admin I'll take a slight performance hit over security any day. PHP is the #1 method hackers compromise accounts so every little additional protection helps.
    Larry Ludwig
    Empowering Media
    HostCube - Proactively Managed Xen based VPSes
    Empowering Media - The Dev Null Blog

  10. #10
    Join Date
    Jan 2004
    Posts
    1,183
    Quote Originally Posted by zincoxide View Post
    He did admit that he wasn't aware of the security risks involved (if any) by using FastCGI. He said that running PHP in CGI mode alone was a big risk but he didn't know about FastCGI.

    Then, when I told him that I am running suPHP and he said it was an even bigger risk.
    I think he means that suPHP main core runs as root than user runs at their username so if suPHP has any security/hole you will get root hacked because of suPHP rather than nobody hacked.

    The best way to secure would be chroot but that causes a lot of problems when your supporting many platforms.

  11. #11
    Join Date
    Jan 2006
    Location
    Sydney, Australia
    Posts
    251
    Well. I think at the end of the day we can all conclude that neither suPHP nor mod_php (or run PHP as a common user) is the be all and end all secure solution. You either allow the users to shoot their own foot a BIG TIME, or allow the possibility for users to shoot each other's foot...

    A chroot solution with PHP running as a different user than the script owner will be the best I think, so a mis-bebaving script cannot write outside its jail, nor the scripts/directories it invoked from. That is why we have this forum here, as VPS is the easiest way to put scripts into jails.

  12. #12
    Join Date
    Jan 2004
    Posts
    1,183
    Quote Originally Posted by ylsy View Post
    Well. I think at the end of the day we can all conclude that neither suPHP nor mod_php (or run PHP as a common user) is the be all and end all secure solution. You either allow the users to shoot their own foot a BIG TIME, or allow the possibility for users to shoot each other's foot...

    A chroot solution with PHP running as a different user than the script owner will be the best I think, so a mis-bebaving script cannot write outside its jail, nor the scripts/directories it invoked from. That is why we have this forum here, as VPS is the easiest way to put scripts into jails.
    This can be done with some tweaks (modsec), but I havent tested this as it requires apache2.2.

  13. #13
    Join Date
    Jan 2006
    Posts
    264
    Thanks for the input.

    But nobody gave me the direction on how to "properly setup FastCGI PHP & suPHP"

    What settings should I double check?

  14. #14
    Join Date
    Jan 2004
    Posts
    1,183
    Quote Originally Posted by zincoxide View Post
    Thanks for the input.

    But nobody gave me the direction on how to "properly setup FastCGI PHP & suPHP"

    What settings should I double check?
    Re read the thread and suphp page you clearly don't understand what was said.

Posting Permissions

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