Posts Tagged ‘suhosin’

How to get rid of “PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php5/20090626/suhosin.so'” on Debian GNU / Linux

Tuesday, October 25th, 2011

PHP-warning-how-to-fix-warnings-and-errors-php-logo

After a recent new Debian Squeeze Apache+PHP server install and moving a website from another server host running on CentOS 5.7 Linux server, some of the PHP scripts running via crontab started displaying the following annoying PHP Warnings :

debian:~# php /home/website/www/cron/update.php

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626/suhosin.so' – /usr/lib/php5/20090626/suhosin.so: cannot open shared object file: No such file or directory in Unknown on line 0

Obviously the error revealed that PHP cli is not happy that, I've previously removes the suhosin php5-suhosin module from the system.
I wouldn't have removed php5-suhosin if sometimes it doesn't produced some odd experiences with the Apache webserver.
To fix the PHP Warning, I used first grep to see, where exactly the suhosin module gets included in debian's php.ini config files. debian:~# cd /etc/php5
debian:/etc/php5# grep -rli suhosin *
apache2/conf.d/suhosin.ini
cgi/conf.d/suhosin.ini
cli/conf.d/suhosin.ini
conf.d/suhosin.ini

Yeah that's right Debian has three php.ini php config files. One for the php cli/usr/bin/php, another for the Apache webserver loaded php library/usr/lib/apache2/modules/libphp5.so and one for Apache's cgi module/usr/lib/apache2/modules/mod_fcgid.so .

I was too lazy to edit all the above found declarations trying to include the suhosin module in PHP, hence I remembered that probably all this obsolete suhosin module declaration are still present because probably the php5-suhosin package is still not purged from the system.

A quick check with dpkg , further strenthened my assumption as the php5-suhosin module was still hanging around as an (rc – remove candidate);

debian:~# dpkg -l |grep -i suhosin
rc php5-suhosin 0.9.32.1-1 advanced protection module for php5

Hence to remove the obsolete package config and directories completely out of the system and hence solve the PHP Warning I used dpkg –purge, like so:

debian:~# dpkg --purge php5-suhosin
(Reading database ... 76048 files and directories currently installed.)
Removing php5-suhosin ...
Purging configuration files for php5-suhosin ...
Processing triggers for libapache2-mod-php5 ...
Reloading web server config: apache2.

Further on to make sure the PHP Warning is solved I did the cron php script another go and it produced no longer errors:

debian:~# php /home/website/www/cron/update.php
debian:~#

Disabling PHP system(); and exec(); functions to raise up Apache security on Debian GNU / Linux

Wednesday, July 18th, 2012

Disabling PHP system(); and exec(); functions to raise up Apache security on Debian Gnu / Linux

At security critical hosts running Apache + PHP based sites it is recommended functions like:

system();
exec();shell_exec();.....

to be disabled. The reason is to mainly harden against script kiddies who might exploit your site/s and upload some shitty SK tool like PHP WebShell, PHP Shell and the probably thousands of “hacker” variations that exist nowdays.

In latest Debian stable Squeeze, suhosinadvanced protection module for php5 is being installed and enabled in Apache (by default).
Simply disabling a number of functions using suhosin, could prevent multiple of future headaches and hours of pondering on who 0wn3d your server ….

Disabling the basic PHP system(); and other similar functions which allows shell spawn is not always possible, since some websites or CMS platforms depends on them for proper runnig, anyways whether it is possible disabling ’em is a must.
There are two ways to disable system(); functions; One is through using /etc/php5/apache2/conf.d/suhosin.ini and 2nd by adding a list of functions that has to be disabled directly in Website Virtualhost file or in apache2.conf (/etc/apache2/apache2.conf;
For people hosting multiple virtualhost websites on the same server using the custom domain Virtualhost method is probably better, since on a global scale the functions could be enabled if some of the websites hosted on the server requires exec(); to work OK. In any case using /etc/php5/apache2/conf.d/suhosin.ini to disable system(); functions in PHP is less messy …

1. Disabling PHP system(); fuctions through /etc/apache2/apache2.conf and custom site Vhosts

Place somewhere (I prefer near the end of config);;;


php_admin_flag safe_mode on
php_admin_value disable_functions "system, exec, shell_exec, passthru , ini_alter, dl, pfsockopen, openlog, syslog, readlink, symlink, link, leak, fsockopen, popen, escapeshellcmd, apache_child_terminate apache_get_modules, apache_get_version, apache_getenv, apache_note,apache_setenv,virtual"

Disabling it for custom virtualhost is done by simply adding above Apache directvies (before the closing tag in /etc/apache2/sites-enabled/custom-vhost.com

2. Disabling PHP system();, exec(); shell spawn with suhosin.ini

In /etc/php5/apache2/conf.d/suhosin.ini add;;

suhosin.executor.func.blacklist =system, exec, shell_exec, passthru, ini_alter, dl,
pfsockopen, openlog, syslog, readlink, symlink, link, leak, fsockopen, popen,
escapeshellcmd, apache_child_terminate apache_get_modules, apache_get_version,
apache_getenv, apache_note,apache_setenv,virtual

To do it directly via shell issue;;;

server: conf.d/# cd /etc/php5/apache2/conf.d/
server: conf.d# echo 'suhosin.executor.func.blacklist =system, exec, shell_exec, passthru, ini_alter, dl,' >> suhosin.ini
server: conf.d# echo 'pfsockopen, openlog, syslog, readlink, symlink, link, leak, fsockopen, popen,' >> suhosin.ini
server: conf.d# echo escapeshellcmd, apache_child_terminate apache_get_modules, apache_get_version,' >> suhosin.ini
server: conf.d# echo 'apache_getenv, apache_note,apache_setenv,virtual' >> suhosin.ini

Then to re-load the memory loaded Apache libphp library an Apache restart is necessary;

server: conf.d# /etc/init.d/apache2 restart
Restarting web server: apache2 ... waiting .
server: conf.d#

Tadam, this should be quite a good security against annoying automated script attacks. Cheers 😉