Stop exploits and malicious execs: safe mode help needed.

[fenixer]

Hello...

Finally, I decided to apply PHP safe mode to my servers, considering:

- I cannot prohibit using exec functions (some binary uses are needed, like host, mysqldump, etc..)

- I cannot restrict at all via UID/GID method at bins due to several problems..

Safe mode is the final sollution, as I only need "safe_mode_exec_dir" config to set a folder with the necesary binaries... this will stop nobody user (Apache) to exec whatever it wants, like perl, binaries uploaded to an public insecure folder (exploits), or anything else... people only could exec() the binaries I want and where I want. This will stop finally 95% of my hack problems.

Well. The problem is safe_mode is enabled or not, but you cannot set o disable certain features of this safe mode, like UID/GID checks (goddamn!)...

I am trying to configure so only "safe_mode_exec_dir" would apply, so:

- Including UIDs checks disabled by:
safe_mode_include_dir = "/home/"
(tested)

- Some variables set to NULL, as safe_mode_allowed_env_vars or safe_mode_protected_env_vars...

- safe_mode_exec_dir = "/usr/phpbin/"
Great! with symbolic lynks in... the best sollution available for me.

- open_basedir = "/home/"
(for fopen, etc...)

Ok ok.. but problems there.. by example this one:

Warning: fopen() [function.fopen]: SAFE MODE Restriction in effect. The script whose uid is 32015 is not allowed to access cache/dynamic_fields/modules.php owned by uid 99 in /home/yyyyyyyyy/public_html/chn/modules/DynamicFields/DynamicField.php on line 823

Great.. fopen is under UID/GID checks, but it is not an include, so safe_mode_include_dir would not apply...

Now fopen, link, unlink, etc.. functions are UID restricted and this seems to be impossible to disable.... pffffffff...

Please, can you share your safe_mode configs or sollutions for this problem??

Thanks.

 

[darren.nolan]

Just keep in mind a lot of scripts refuse to run on safe_mode enabled. That and I thought PHP 5+ were ditching the option altogether?

We use a combination of Suhostin suPHP and Mod_Security and finally 99% of the silly exploits in scripts like joomla are sorted (grr to global-registers and emulation for it).

I say 99% because something may happen tomorrow. Touch wood.

Edit: Appears only PHP6+ have this feature removed.

 

[simoesp]

i use « allow_url_fopen = Off » on my server it's better then safe mode :P it prevents lots of scripts to be included externally principally on joomla and other CMS vulnerabilities

 

[darren.nolan]

i use « allow_url_fopen = Off » on my server it's better then safe mode :P it prevents lots of scripts to be included externally principally on joomla and other CMS vulnerabilities

This is a good move before going to SafeMode imho.

 

[fenixer]

Helo... you are lucky if with those options are keeping your servers secure.

In my case the thing is a bit difficult, and like you, I use:

- modsec with hundred running rules.
- allow_url_fopen = Off of course
- do not use phpsuexec, but have cron-ned a script each minute checking nobody's proccess looking for not allowed..

The biggest problem (you are not having at all it seems) is:

- Several CMS allows uploading contents (by example a PHP-SHELL!!!!!), and with this php-shell someone can execute several system commands (except those one at modsec) and finally, UPLOAD a perl script and execute it through an exec to perl or a binary (trying to exploit my kernel), or a owned shell, and execute it.

Like I said, if I can control what can be executed (at my safe binary folder) and whatś not, EXPLOITING SOMETHING would be almost impossible, as it doesnt matter joomla has a new hole at any module not specified at modsec. The 95% of my problems are gone.

Just keep in mind a lot of scripts refuse to run on safe_mode enabled

Some examples please? The biggest problem (and I think the only one) I can figure out I will have (after checking documentation) is the UID/GID checks while some functions like fopen, etc...

http://us3.php.net/manual/en/features.safe-mode.functions.php

I am bit sad because this UID/GID checks seems to be not allowed to disable and it makes the use of safe_mode only possible if I use phpsuexec also....

 

[darren.nolan]

Consider using function disable in your php.ini - disable things like passthru and system etc. Stop people not from uploading php-shell scripts, but stop those scripts from executing.

phpsuexec is all but disappeared. suPHP will force php to run as the user. So when they try to use shell commands - those commands executed (like system('ls')) will been executed as their username. I'm almost 100% certain this happens on small tests I have done, can cPanel confirm?

Using suExec will then start to lock down executed perl scripts to run also as the user - rather than "nobody".

I would not normally recommend suhostin - but I installed it a few months ago in a desperate attempt at stopping CMS exploits. My biggest fear was cracking down on security so much that normal things would start to break. This was not the case however, and you can always tweak suhostin.

Edit: I believe Mambo off the top of my head doesn't work with safemode enabled.
Edit2: I think the correct syntax for adding to your php.ini file is disable_function = system, exec, shell_exec

 

[bsdjunk]

Most scripts which are programed by morons, newbies or people starting out in PHP will not make the workarounds for using safe_mode. I know Joomla works with safe_mode and some others. If it will help in limiting the ability to run scripts that do damage then it is wise to use it. PHP is very insecure by itself but it is still one of the most popular web page scripting languages available along with the others IE Perl, Python, Ruby but PHP is the most insecure this is because most people dont think of security out of the box but rather script the app and wait for exploits to come in fix them and thats it.

 

[fenixer]

Helo... thanks for your answers...

I am not very happy about disabling functions, so much modules and CMS uses exec() to chown, mysqldumps, etc... I consider this as necessary for some clients.

Suphp is not necessary for me, since it will significate a pain for me, just because i am running like 1300 accounts used to stablish their owns phpflags at .htaccess... if I compile with suphp, I need to:

- script to chown all files at public_html (easy)
- script to chmod 755 all directories and 644 all files because if not, they would be refused by php. (easy)
- script to find and remove all phpflags at .htaccess files anywhere. (difficult)
- disable my anti-nobody-non-legitimal-script... why? because even if I modify it to check for all users (bucle), there are many many many more proccess allowed for an user, rather than http and 5 or 6 else for nobody. It would be a pain to check all possible proccesses allowed for an user. SO I cannot check automatically exploits or something else. (pffff)
- convert those phpflags to php.ini (pffffffffffffffff) and link them at virtualhosts (pfffffFFFFF!)

also, I would not be so happy with the idea of an user modifying their own php.ini (unless I chown to root that file at their homes).

But Suhosin seems to be a great idea.... really...

Check this:
http://forum.hardened-php.net/viewtopic.php?id=411
(this would be lovely, but i am afraid it would not be done until several months... if it is finally done, of course)

 

[darren.nolan]

In regards to change your .htaccess into their own php.ini file check out http://corz.org/devblog/2006-Q1/phpsuexec

I sort of fell over it while surfing tonight. I haven't tried it, nor have I probably read it right. It's rather late here and I need more coffee. Of course that's not to change your mind about not using suPHP - just some food for though.

But I don't fully understand your concerns here. Could you please explain a little.

* script to find and remove all phpflags at .htaccess files anywhere. (as pointed out above)
* convert those phpflags to php.ini (also as above) - and link them at virtualhosts - Place the flags in their virtualhost entry at apache level? You could just let users use their own php.ini file.

* disable my anti-nobody-non-legitimal-script... why? because even if I modify it to check for all users (bucle), there are many many many more proccess allowed for an user, rather than http and 5 or 6 else for nobody. It would be a pain to check all possible proccesses allowed for an user. SO I cannot check automatically exploits or something else.

Your last concern is the one I get lost with the most. What is it exactly that your script searches for in regards to exploits? In the php script files themselves or like running processes?

Edit: You have lock down on .htaccess files at the moment with your current setup? If you don't I can't see a difference letting users have a php.ini file rather than .htaccess. Of course it's not so cut and dry or as simple as "just that" - but you could easily adjust your script or write a new one to target php.ini files to ensure firstly they aren't blank (kills your global php.ini settings on my last check) or uses things like disable_functions = ''

 

[fenixer]

Hi!!!

Thanks for your interest... here I am:

The script for automatically detect and kill (and log and mail) nobody's non legitimal process running is at: http://www.webhostgear.com/353.html

I use a modified version, adding a top, some lsof and new rules... for nobody, there are around 10 or 11 process allowed. Any other kind of process not included at the rules will cause kill and logs == 99% possible exploit. I am running it each minute (created a PID to avoid running it twice). It is a good way to be notified about anything not normal.

I can modify it to read all users at system, and with a for bucle scan the process of the existing users due to rules (of allowed ones), but now, with suphp, it would include 20-30-40-unlimited(cgis) possible proccess.. difficult to filter.. hard to change at production, you know... it would be better to not-using this kind of cronjob (each minute), so I could not auto-detect-kill-and-log some non desired process in execution == more monitoring jobs for me, but it is a price to pay for increasing security, I guess.

Well.. I thought with suPHP, if you want to use a php.ini for a virtualhost (user), you should include the path at the current virtualhost at httpd.conf... isn't true? (suPHP_ConfigPath at virtualhost)

And finally, I cannot force 1300 accounts (estimated) to create quickly a php.ini with the register_globals rules (and something else) because I updated my config (to suPHP) and their webs are down!! it is difficult to think that way in my case (most of clients does not understand nothing about php.inis or .htaccess). I need to programme a script to do it automatically, extracting (and removing) the phpflags at .htaccess files, and translating into the current php.ini at their paths... for me, I think it is a bit difficult (but you know, nothing is impossible) I would preffer to enable the typical rules, like enabling globally the register_globals until found sollutions.

I think suPHP is great, but not using it allows me to distinguish perfectly what is doing PHP and Apache through nobody user (the most hacks come here=). I think, IMHO the most interesting way of securing our webservers is controlling what can be executed and what not. Control (or deny) the exec functions of php is necessary for this. It is a pitty the way safe_mode assume this, but you cannot use it without breaking many websites due to other checks and prohibitions not so necessary. Don't you think?

Note: the URL you provide is good!! thanks.

Thanks so much!

 

[darren.nolan]

Hrmm - interesting.

Well the .htaccess PHP flags to php.ini shouldn't be a problem using to scripts on the link I gave you - if you were ever interested in going that way.

I like suPHP as if one account is hacked - the best they can do is stuff up that account.... Rather than anything that's rights are available at 777 (which many scripts call for).

Let me know what you do in any case. All very interesting