PHP hardening patch - Suhosin

Posted by simonw on Fri 16 Feb 2007 at 08:51

PHP has a notorious security history, but web hosts have to provide it. Suhosin is a security patch that can be applied to change behaviour of the default PHP install in security related ways, and is now packaged in Debian Etch and Sid, with some of it built into the default PHP builds, and some available as an extra.

To install and test;

Create a PHP file somewhere on your website with this in, and view it with Apache to see your PHP config.

<?php
phpinfo();
?>;

When viewed the page should claim that Suhosin is included, but Suhosin directives in the PHP5 ini files will have no effect.

apt-get install php5-suhosin

I assume people have PHP5 installed by now!

Viewing the PHP info page should now have a whole section to "Suhosin" showing the value of settings like "suhosin.mail.protect".

As a quick test it is working, we disable phpinfo;

echo suhosin.executor.func.blacklist="phpinfo" >>/etc/php5/conf.d/suhosin.ini
/etc/init.d/apache2 restart

Reloading the phpinfo page, should now be blank, and an error logged something list this one;

[Wed Feb 14 13:30:08 2007] [error] [client ip.ad.dr.es] ALERT - function within blacklist called: phpinfo() (attacker 'ip.ad.dr.es', file '/home/gardens/phpinfo.php', line 2)

Of course one can blacklist functions in PHP without Suhosin, the interest is more in the features like the mail function protection.

This note was written as I couldn't find an introduction, the author is not an expert in PHP security!

 

 


Posted by Anonymous (213.164.xx.xx) on Fri 16 Feb 2007 at 10:39
Why would you disable phpinfo()? It gives developers/customers the information they need to write scripts.

Why would you use Suhosin? If you want to disable functions, you can do this form php.ini?

[ Parent | Reply to this comment ]

Posted by Anonymous (213.164.xx.xx) on Fri 16 Feb 2007 at 10:43
> Of course one can blacklist functions in PHP without Suhosin
Ah.

> the interest is more in the features like the mail function protection.
Newline protection?

The features are listed here:
http://www.hardened-php.net/suhosin/a_feature_list.html
but it's difficult to find an "oh that's nice" feature.

[ Parent | Reply to this comment ]

Posted by Anonymous (80.68.xx.xx) on Fri 16 Feb 2007 at 11:01
It is hard to know how useful things will be without configuring the module explicitly.

Some of the memory protection, for example, seems like a good idea. But is it really useful?

[ Parent | Reply to this comment ]

Posted by colabus (203.87.xx.xx) on Fri 16 Feb 2007 at 11:00
[ View Weblogs ]
Nice find, this also is setup for stable too, just gotta add the dotdeb site to sources.
deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all
-- colabus blogspot colabus requiem

[ Parent | Reply to this comment ]

Posted by chris (213.187.xx.xx) on Sat 17 Feb 2007 at 11:30
[ View Weblogs ]
I thought I'd give this a try - just to see what it does.

I can say that the default config (etch) broke:

phpmyadmin login - cookie based login - irrespective of what user name you try to log in with it tries to use www-data@localhost

drupal - saving access permissions (seems to be the only thing - most of the rest works).

So - definitely something to test on a test install first.

[ Parent | Reply to this comment ]

Posted by simonw (84.45.xx.xx) on Sat 17 Feb 2007 at 11:44
[ View Weblogs ]
There is a suggestion on the Suhosin site, that this can be due to a stale cookie, if you enabled the cookie encryption.

Seems cookies sent before installation are assumed to be encrypted ("a don't start from here" situation), when they obviously are not.

I'd be interested to know if deleting the cookie fixes this issue.

[ Parent | Reply to this comment ]

Posted by chris (213.187.xx.xx) on Sat 17 Feb 2007 at 12:10
[ View Weblogs ]
I'll give it a go when I get a second machine up and running.

It may be the case. But - I wonder exactly which cookie it is if so - the error was happening at login - when the cookie is supposed to be created (I don't use persistant cookies for my phpmyadmin and the box has been restarted since suhosin was enabled).

[ Parent | Reply to this comment ]

Posted by chris (213.187.xx.xx) on Sat 17 Feb 2007 at 12:31
[ View Weblogs ]
Threw it on the live box for a quick test.

The stale cookie issue is the problem with phpmyadmin (works fine after removing cookies).

The saving of access permissions under drupal - no - that still fails.

[ Parent | Reply to this comment ]

Posted by simonw (84.45.xx.xx) on Sat 17 Feb 2007 at 17:22
[ View Weblogs ]
Maybe session-cookies?

Suhosin is pretty widely installed, and many Drupal folk use it, so I'd be surprised if it wasn't either state information, or a known issue.

[ Parent | Reply to this comment ]

Posted by chris (213.187.xx.xx) on Sat 17 Feb 2007 at 19:01
[ View Weblogs ]
I removed all cookies that were that server - so - it can't really be an old one. I know that the only form that fails has several hundred checkboxes (a matrix of maybe 20 groups and 40-45 permissions) - so it could be a size issue.

[ Parent | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Sun 18 Feb 2007 at 11:11
[ View Steve's Scratchpad | View Weblogs ]

Bug report?

Steve

[ Parent | Reply to this comment ]

Posted by chris (213.187.xx.xx) on Sun 18 Feb 2007 at 11:24
[ View Weblogs ]
Question is - a bug in suhosin or a bug in drupal? Am I guaranteed that suhosin in default configuration is totally transparent.

On top of that - I am not running the drupal deb package - since I have several areas checked out of CVS, etc etc.

I reckon I need to do more reading and investigating first.

[ Parent | Reply to this comment ]

Posted by Anonymous (71.211.xx.xx) on Fri 28 Jan 2011 at 00:32
Just for posterity (this thread came up high in search results) -- suhosin does not expose Drupal bugs, but certain Drupal functions can exceed default suhosin limits, namely suhosin.post.max_vars and suhosin.request.max_vars if you have lots of data. In my case it was a Block Admin screen with lots and lots of blocks defined -- it wouldn't save, and seemed to just silently fail. Since suhosin logs to syslog by default, the problem was not immediately obvious looking just at the apache log. I imagine the same is possible for any admin screen with giant forms (the permissions grid, for example)

You may need to increase some of the config values from their defaults if running a data-heavy Drupal site. Make sure you check syslog for suhosin alerts if you suspect such a failure.

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 526 votes ~ 7 comments )

 

 

Related Links