Page 2 of 2 FirstFirst 12
Results 26 to 49 of 49
  1. #26
    Join Date
    May 2006
    Location
    Coimbra, Portugal
    Posts
    236
    Quote Originally Posted by flashwebhost
    Only when you have phpsuexec installed ?
    If phpsuexec or suphp aren't installed the processes will run as apache which is a big issue.

    Running as apache i can do the following:
    <?system("cat /etc/passwd");?>
    (Check all system users)
    <?system("ls /home/usernames_on_passwd_file/public_html");?>
    (List all user files/directories)
    <?system("tar -cf /home/my_home_dir/public_html/bad_guy.tar /home/usernames_on_passwd_file/public_html/");?>
    (Compact all user files into a tar)

    Since usually config.incs with mysql passwords are stored inside public_html you can easily get hacked if you have php without suexec and with:
    system fuction enabled (openbasedir has no effect in this function)
    shell_exec / exec if openbasedir is disabled

  2. #27
    Join Date
    Apr 2004
    Location
    Australia
    Posts
    456
    Quote Originally Posted by sspt
    If phpsuexec or suphp aren't installed the processes will run as apache which is a big issue.

    Running as apache i can do the following:
    <?system("cat /etc/passwd");?>
    (Check all system users)
    <?system("ls /home/usernames_on_passwd_file/public_html");?>
    (List all user files/directories)
    <?system("tar -cf /home/my_home_dir/public_html/bad_guy.tar /home/usernames_on_passwd_file/public_html/");?>
    (Compact all user files into a tar)

    Since usually config.incs with mysql passwords are stored inside public_html you can easily get hacked if you have php without suexec and with:
    system fuction enabled (openbasedir has no effect in this function)
    shell_exec / exec if openbasedir is disabled
    Thats what mod_security is for, and all my experiences with openbasedir have prevented any access outside of the directory's specified, I will do some testing when I get time.

  3. #28
    Join Date
    Mar 2005
    Posts
    361
    I´m using phpsuexec on cpanel for at least 3 years without big problems... I got only with very OLD scripts, and since 1 year ago I dont have any kind of trouble.

    My only problem is related on running php caches like eaccelerator / APC, they didnt seem to work with phpsuexec enabled.

  4. #29
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,737
    Quote Originally Posted by scribby
    Thats what mod_security is for, and all my experiences with openbasedir have prevented any access outside of the directory's specified, I will do some testing when I get time.
    You have to be kidding if you think mod_security would prevent any aspect of that script running; is that what you meant? I know openbasedir **might** (does it restrict the system() and passthru() functions?) help, but it makes a mess of a lot of PHP functions that are used by real life scripts.

    It's impossible to write a script that will tell in every instance what user started a script without phpsuexec (*). That's one reason why phpsuexec is so valuable. Another reason is that it prevents the "tar cf somefile /home/dirs/public_html" style of attack mentioned above.


    You can resist this all you like, but the arguments are getting more and more ridiculous and baseless; phpsuexec is not a bandaid; it's only part of a security solution, you need other things as well, but it is so good at what it does that it's essential, in my opinion.


    (*) A running script can very easily obliterate all identifying traces, even so that you can't look at it with lsof or other similar tools.

  5. #30
    The only disadvantages which I see with phpsuexec are the following:

    - php scripts are not running in symlinks
    - phpauth is not working anymore

    Another advantage is, if a script is creating a file, the customer has the right to delete the file again, because it's owned by the user.

    We are using now phpsuexec sind 2 years and love it.

    Mike

  6. #31
    Join Date
    Apr 2004
    Location
    Australia
    Posts
    456
    Quote Originally Posted by brianoz
    You have to be kidding if you think mod_security would prevent any aspect of that script running; is that what you meant? I know openbasedir **might** (does it restrict the system() and passthru() functions?) help, but it makes a mess of a lot of PHP functions that are used by real life scripts.

    It's impossible to write a script that will tell in every instance what user started a script without phpsuexec (*). That's one reason why phpsuexec is so valuable. Another reason is that it prevents the "tar cf somefile /home/dirs/public_html" style of attack mentioned above.


    You can resist this all you like, but the arguments are getting more and more ridiculous and baseless; phpsuexec is not a bandaid; it's only part of a security solution, you need other things as well, but it is so good at what it does that it's essential, in my opinion.


    (*) A running script can very easily obliterate all identifying traces, even so ththat you can't look at it with lsof or other similar tools.
    Openbasedir does not restirct any functions, it stops scripts/functions accessing outside of the directorys you specify.

    This then stops access to the bin file so you cant access commands like reboot, cat, ls, etc, tar... also stop people accessing the passwd file and other users home directorys.

    Openbasedir along with a CORRECTLY configured modsecurity ruleset is just as good as installing phpsusexec.

  7. #32
    Join Date
    Mar 2004
    Location
    Odessa, Ukraine
    Posts
    610
    I know a lot of tricks for avoid openbasedir. Hackers know more than me.

  8. #33
    Join Date
    Oct 2004
    Location
    India
    Posts
    509
    phpsuexec is now not maintained. cPanel picked it up and works on it so that it can be included with it.

    suPHP is the best options nowadays.
    ESC :wq!

  9. #34
    Join Date
    Apr 2004
    Location
    Australia
    Posts
    456
    Quote Originally Posted by andreyka
    I know a lot of tricks for avoid openbasedir. Hackers know more than me.
    Thats like me saying I know lots of tricks to avoid phpsu.

    The fact is that not just one extra security program is going to help you, you will need multiple.

  10. #35
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,737
    Quote Originally Posted by scribby
    The fact is that not just one extra security program is going to help you, you will need multiple.
    Absolutely ... real security is a multi-layer approach. You don't win a war by giving soldiers new shirts; you win by having good body armour, weaponry, mobile tanks, inbuilt defences, perimeter monitoring and all those good things.

    Quote Originally Posted by scribby
    Openbasedir does not restirct any functions, it stops scripts/functions accessing outside of the directorys you specify.
    Well, it doesn't restrict too much but it does stop nearly every sophisticated script from running so should be unacceptable to any host that allows programming.

    Quote Originally Posted by scribby
    This then stops access to the bin file so you cant access commands like reboot, cat, ls, etc, tar... also stop people accessing the passwd file and other users home directorys.
    These should be protected by ownership and permissions, with root only access to the critical commands. Things like "reboot" require root permission to work, and it's actually the bin *directory*, in case you didn't realize.

    Quote Originally Posted by scribby
    Openbasedir along with a CORRECTLY configured modsecurity ruleset is just as good as installing phpsusexec.
    You just don't understand what phpsuexec or suPHP do, as they're not the same as openbasedir at all. And one should also run mod_security with phpsuexec, to not do so is foolish. Openbasedir adds little in the way of protection (it can be circumvented, probably easily), breaks scripts, and generally adds a false sense of security.

    The true value of phpsuexec is that it allows unix file system and user security to keep running processes apart. This keeps users out of each other's files, makes it clear where spam is coming from, and helps isolate the source of runaway processes.

    I'm not saying openbasedir doesn't help, just that I think it's a weaker solution than phpsuexec for simple architectural reasons - having all the users on the system share the same userid and file access rights is architecturally ludicrous.

  11. #36
    Is it true that eaccelerator doesn't work with phpsuexec?

    What about with suPHP?
    Ajay D'Souza

    WebberZone

  12. #37
    Join Date
    Apr 2004
    Location
    Australia
    Posts
    456
    Quote Originally Posted by Webberzone
    Is it true that eaccelerator doesn't work with phpsuexec?

    What about with suPHP?
    I heard phpsuexec is not developed anymore so you should use suPHP anyways?

  13. #38
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,737
    Quote Originally Posted by Webberzone
    Is it true that eaccelerator doesn't work with phpsuexec?

    What about with suPHP?
    phpsuexec and suphp both work by running the php instance separately under a separate userid. This adds enormously to security but breaks all php acceleration attempts that work by caching code, as there's nowhere to cache any more. So, yes, they don't work with phpsuexec and I'm fairly sure they don't work with suPHP. It actually should be possible to develop something perhaps caching in shared memory but it's not trivial.

    phpsuexec isn't developed any more but that's mostly irrelevant as it doesn't need to change, and it's standard on cpanel servers.

    If you're running a heavily loaded server, suPHP/phpsuexec will slow you down noticeably - just how much depends on the exact pattern of PHP usage - can vary from 20 to 1000 times from reports I've heard. It won't slow you down if the usage is widely spread - it will slow you down if there are a few heavily accessed accounts.

  14. #39
    Quote Originally Posted by Scott.Mc
    1. Very easy, there are lots of methods and if they all fail just strace the processes and you will find out quite quickly.

    2. Why did you notice a day later? Mod_security, rename binarys, posix acls will all help stopping and reducing the effects of this.

    Logs should be available when you look at it, to make it easy to track.

    -Scott
    Scott is totally right for all what he said...

    if you are all talking about tracking hacked users ... files got in /tmp........ etc
    whatever !!!!!! why would u let them to get in there !!!
    but what you didn't notice... With a simple Exploit in a client website like remote include...... first of all he won't have hard thoughts to find a 777 Directory to upload a shell script to it.. because he is already have the USER permission not nobody or something.. and in same time he can easily use the shell scripts to edit the website index >>>>>> DEFACING it easily or deleting it even.. !!
    and even another tweak i hate in phpsuexec.. that they can overwrite your php.ini settings with simply uploading a php.ini in a directory
    thats usefull for some ppl .. but i don't like to be easy target for anyone...

  15. #40
    Quote Originally Posted by andreyka
    I know a lot of tricks for avoid openbasedir. Hackers know more than me.
    looooooooooooool me2 open_basedir and safe mode , suexec also
    priv8 world r0x

  16. #41
    Join Date
    May 2004
    Location
    Norway
    Posts
    20
    Hi,

    I have a dedicated server with many hosting clients. I'm considering to enable the phpsuexec.

    Is it possible to disable/uninstall phpsuexec if I find out that I can't use it? Will the system revert back to it's initial state after disabling the phpsuexec?

  17. #42
    Join Date
    May 2003
    Posts
    1,708
    Adding phpsuexec to a server that is already loaded with customers will be a nightmare. Enable it only on new servers and then start putting customers off. Once it is on it is easy to remove, just not easy to add after the server has customers.

    The nobody mail bounces from php scripts is another advantage of phpsuexec. I know it is a small thing, but it is nice that scripts do run as a userid instead of nobody.
    ~~~~~~~~~~~~~~~~~~~~~
    UrNode - Virtual Solutions
    http://www.UrNode.com

  18. #43
    Join Date
    Sep 2005
    Location
    In canada
    Posts
    3,374

    *

    Quote Originally Posted by Scott.Mc
    I personally do not use it, in terms of "security" it may be easier to catch certain things however it will generally cause alot of problems and probably better just to leave it.
    Hello Scott,
    Might i ask if its a headache on a server and according to your personal viewpoint you do not like it on servers, why you installed phpsuexec on my new server (remember 2 -3 months back) ?

    And if i am not mistaken on MSN you mentioned its better to have it from secuirty stand point, has that changed after 2 months now ?

    If i recall correctly it was not on my vps prior to moving to dedicated server. And i had no clue or any instructions given to get suexec installed.

    I just would like to know is suexec really good or just PITA(in short for pain in the ***) as mentioned by many learned folks around here?
    12+ years -same website , new server [SSD Inside] providing shared/reseller hosting only !
    These things we do not provide/offer : Unlimited Storage ! Unlimited Bandwidth ! But Why? Cause, we were unable to put such a large number on our pages, it just would not fit.
    So check out the numbers that actually fit >> << the page as well as your budget too !

  19. #44
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,737
    If you understand what phpsuexec does, and have some basic cpanel knowledge and a little scripting ability, it's not hard to add to an existing server. Many people have done it and there are comments everywhere saying they didn't find it hard.

    paidhosting: yes, it's pretty much definitely the way to go. If you have many heavy-use PHP forums then you might not use it as it can be slower in that scenario than PHP running as a module, but for the average server it's a win-win - better security and traceability in several ways.

  20. #45
    Join Date
    Apr 2004
    Location
    Australia
    Posts
    456
    Quote Originally Posted by brianoz
    If you understand what phpsuexec does, and have some basic cpanel knowledge and a little scripting ability, it's not hard to add to an existing server. Many people have done it and there are comments everywhere saying they didn't find it hard.
    I wouldn't add it to an existing server unless you had really good support, you will get flooded with complaints about permissions not working etc... as to my knowledge you cant use 777 so anyone using 777 permissions would get an error page if I'm right? and this would cause allot of complaints and require allot of support to help people with the changes.

  21. #46
    Join Date
    May 2004
    Location
    Norway
    Posts
    20
    Quote Originally Posted by scribby
    I wouldn't add it to an existing server unless you had really good support, you will get flooded with complaints about permissions not working etc... as to my knowledge you cant use 777 so anyone using 777 permissions would get an error page if I'm right? and this would cause allot of complaints and require allot of support to help people with the changes.
    There is a function in WHM called "Fix Insecure Permissions (Scripts)", named /scripts2/fixsuexeccgiscripts. I believe this has something to do with suexec. Wouldn't this fix the permission issues or do I need to take some more actions in order to fix all the permission issues?

  22. #47
    Join Date
    May 2003
    Posts
    1,708
    No, it wouldnt. The problem is things like Gallery call for the g2data directories to be 0777 and that wouldn't change something like that. If you add phpsuexec to an existing server you will get lots of tickets about scripts now being broken and returning 500 Internal Errors. It is easy to fix, but be prepared.
    ~~~~~~~~~~~~~~~~~~~~~
    UrNode - Virtual Solutions
    http://www.UrNode.com

  23. #48
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    We use phpsuexec alot, we usually start out like this.

    chown all files in users public_html to them (user:user)
    chmod all directories to 755
    chmod all files to 644

    this normally results in very little problems. Also we check .htaccess files for offending rules
    If you know bash scripting its pretty easy to make up a script to do the above.
    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

  24. #49
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,737
    Quote Originally Posted by scribby
    I wouldn't add it to an existing server unless you had really good support, you will get flooded with complaints about permissions not working etc... as to my knowledge you cant use 777 so anyone using 777 permissions would get an error page if I'm right? and this would cause allot of complaints and require allot of support to help people with the changes.
    Probably best not to comment on this unless you have actual experience with it. It just confuses the issue; people assume you understand what's involved, but you sound like you've never used phpsuexec and don't understand the issues. Not meaning to be offensive, just calling it straight. That's assuming you were making a comment rather than asking a question of course!

    You don't need 777 permissions any more with phpsuexec, files can now we uploaded without needing to have directories mode 777 - the script owner can always upload to his own directories unless specifically disabled. Phpsuexec doesn't solve every security problem, but it is a useful ally. Steven's post above is right on the money, ie, it's safe to modify 777 permissions to 755, and your scripts will work.

    The /scripts/fixsuexeccgiscripts (aka /scripts2/fixsuexeccgiscripts I assume) script just checks the suexec log for permission problems with scripts and fixes the specific errors that have occurred. It doesn't do a permission update for everything and that's definitely what should be done first - again, just what Steven recommended.

    The only instance where a script might not work is if it foolishly explicitly tests for 777 permissions. Any sane script should check for write access (by creating a test file) rather than explicitly checking permissions, so I wouldn't expect many scripts out there will break from that.

Page 2 of 2 FirstFirst 12

Posting Permissions

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