Results 1 to 11 of 11
  1. #1
    Join Date
    Feb 2004
    Posts
    1,226

    securing PHP (again...)

    the only real solution i knew - phpsuexec - has 'failed': http://www.webhostingtalk.com/showth...hreadid=277603

    what can we discuss about safemode, open_basedir and disabling functions?

    that will be a long post... i'll start with facts and targets...

    fact: php applications will run as user 'nobody'
    target: our main target is to secure it from not being able to do anything that a perl script can't do (even if we restrict it even more, but must be something suitable for users)

    in target, we include:
    - not be able to read other users dir
    - one that i find most important: not being able to use SUEXEC to "log" as ANOTHER user and do ANYTHING this user can do


    if you get this script sprintserve says here: http://www.webhostingtalk.com/showth...hreadid=275940 you'll notice that if you're not using restrictions, you will be allowed to execute commands as any user!

    ok... so let's start with other facts (i'll assume all this methods do exactly what they say they do and doesn't have security problems):

    phpsuexec
    is a very good solution IMO, but as I already told, that's not a good option... my server load went from 0.4 to 7.0 after I started using PHP as CGI and not apache module

    php_basedir
    prevents users from opening files outside of their home directory with php (from WHM help)

    i don't know exactly how php_basedir does that... maybe limiting functions like "open" (anyone knows?), but it DOES NOT limit, for example:
    <? passthru("ls /home/other_user/www/"); ?>

    disable functions
    IF (i don't know) php_basedir does it job correctly, preventing any php-build-in function to read/access things outside certain directory, all we'd need to do now to have a secure php was to secure php-exec-functions (PS: ALL of them... it won't be secure if you disable all except one)

    discussion: php_basedir + exec functions disabled would probably be a good combination and would really restrict users from reading other users directory and from using SUEXEC to change it username
    the problem: disabling ALL exec functions will cause some scripts to stop working

    safemode
    since it does everything that disable_functions + php_basedir does (but it limits based on user of the file, and not dir AFAIK), the discussion and problem above applies here too.


    real security
    i have an idea for what I call real security:
    php with php_basedir AND suexec for exec functions

    i don't know if it's possible (nor how to do that), but that would probably be a real solution.
    php could still be runned as apache module, but if a php script has any "exec" call, php should use the owner of the .php file (with some checks like "it can't be root") to execute this call

    does anyone knows some patch that does that? or if it's really possible/suitable to do that?

    i'm tired of writing now and you probably tired of reading
    i'll add more comments as you comment on that too

    i hope we can lead to a nice way to secure php, without breaking many applications (i'm really not happy with disabling all exec functions)

  2. #2
    Join Date
    Apr 2003
    Posts
    71
    You can't combine open_basedir, safe_mode and phpsuexec currently.

    I just found out that with a little bit of tweaking you can run php scripts under an sbox as well (http://stein.cshl.org/software/sbox/). Scripts would be running under their own UID's and locked in a box. But you would miss the php caching abilities such as mmcache and take a performance hit like you did with phpsuexec. As a plus, you would not have to worry about safe mode script incompatibilities as php in sbox can securely run with safe mode OFF.

    Or you could just switch to Ensim Pro. You'd still have to secure other parts of your server though.

    You're going to take a performanance hit no matter what if you want php running under individual UID's. However, this would most closely resemble the type of php (not complete) security setup you're talking about.
    Last edited by Eric M; 05-28-2004 at 07:50 PM.

  3. #3
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,294
    the way cpanel sets up accounts you are not going to get as secure as you want to get. you will always have flaws
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  4. #4
    Join Date
    Feb 2004
    Posts
    1,226
    Originally posted by ericfire
    You can't combine open_basedir, safe_mode and phpsuexec currently.
    i never said that

    i said that phpsuexec (and just that) would be a real solution... but has too much impact on performance

    safemode is too radical in my opinion

    my "combination" proposal was open_basedir + disabling exec functions

  5. #5
    Join Date
    Feb 2004
    Posts
    1,226
    Originally posted by thelinuxguy
    the way cpanel sets up accounts you are not going to get as secure as you want to get. you will always have flaws
    what would be a flaw with open_basedir and disabling exec functions?

  6. #6
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,294
    other panels chroot the user, example plesk and ensim. there are ways to bypass both of those methods (open_basedir and disabling exec functions), and experienced php coder could potentially code a script that will do what system, exec, shell_exec, passthru can do. with plesk / ensim you have a more secure model right from the install
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  7. #7
    Join Date
    Apr 2003
    Posts
    71
    When did Plesk start chrooting?

    Originally posted by Lem0nHead
    i never said that
    Sorry, I read you wrong.

  8. #8
    Join Date
    May 2003
    Location
    Florida
    Posts
    877
    So what is the suggested way to secure a Cpanel server used for hosting? Which options do you recommend?

  9. #9
    discussion: php_basedir + exec functions disabled would probably be a good combination and would really restrict users from reading other users directory and from using SUEXEC to change it username
    the problem: disabling ALL exec functions will cause some scripts to stop working
    This is my favorite setup, and IMHO the best compromise on feature loss vs server performance with phpsuexec.

    With as many functions that PHP has, most code should be able to accomplish things without using the exec functions(I said most!!)

  10. #10
    Join Date
    Aug 2002
    Location
    Hong Kong
    Posts
    417
    Originally posted by NEO-Swede
    This is my favorite setup, and IMHO the best compromise on feature loss vs server performance with phpsuexec.

    With as many functions that PHP has, most code should be able to accomplish things without using the exec functions(I said most!!)
    a good programming laguage and most of the scripts associated should alwasy take into considerationthe performance and security, its the programmers' own fault to code scripts to run insecurely, unfortunately its commonly seen in newb php coders

  11. #11
    Originally posted by lwknet
    a good programming laguage and most of the scripts associated should alwasy take into considerationthe performance and security, its the programmers' own fault to code scripts to run insecurely, unfortunately its commonly seen in newb php coders
    Absolutely correct.
    I tend to avoid such scripts that use exec or passthru. There are other languages out there if such a need is absolute, that do not have the security considerations that PHP sometimes bring to the table.
    Dedicated Servers - http://www.neo.net/
    24/7 [email protected] - (800) 508-5076

Posting Permissions

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