PHP 5.4 and suhosin

[BruceLee]

Hi Scott,

since suhosin project seems to be sort of dead....what are your thoughts living without it from security point of view?
rouncube and other stuff are not working correctly like the main developer allready stated.

stefanesser commented a year ago

"Inital support" means that it now compiles against PHP 5.4 in a correct way. However PHP 5.4 has a myriad of code changes and therefore stuff might still be broken.
It is already known that there is a problem with sessions and gallery.

I feel like suhosin starts to make more trouble than it solves.
Would be great to have Atomics point of view.
Thanks

[scott]

Im hurt, all that work into making suhosin work for PHP 5.4 and you didnt even notice

Code: Select all

PHP 5.4.17 (cli) (built: Aug  1 2013 11:12:15) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
    with the ionCube PHP Loader v4.2.2, Copyright (c) 2002-2012, by ionCube Ltd.
    with Suhosin v0.9.34-dev, Copyright (c) 2007-2012, by SektionEins GmbH

Package name is: php-suhosin, there are some 3rd parties maintaining it for PHP 5.4 now.

[BruceLee]

of course I did notice it
I just wondered how the actual state is and what do you think about it. especially from security point of view.
it is one github project moving on but also that one is old. former development is "dead".
it is stated as dev version as well in your repo. so nothing for production.
some errors are known.

so in general I'm thinking about the best way to go with it and therefore asked for your opinion.
Thanks a lot.

[faris]

Unless there is a way to do it that I've not found, suhosin is still the only way I know of that lets you disable loads of php functions then enable them on a domain by domain basis (for mod_php).

Not sure but I assume you can define disable functions on a domain by domain basis with php_fcgi?

Otherwise...not sure. I've not seen a suhosin alert other than something to do with cookie vars or other variable lengths in a long, long time --- mod_sec doing its job, I suppose.

[BruceLee]

my approach here would be to use fcgi implementation of latest Plesk 11.5 and set individual php settings for each vhost via Plesk interface.
currently I use a custom fcgi wrapper that points to individual php.ini's in Plesk 9.5. in those I set everything the way I need to for each vhost like disable functions etc.

The question I'm more interested in is what security benefits suhosin brings us if it is sort of unsupported, not maintained and not really compatible with php5.4.
Parts of it had been implemented in php itself so that its covered without suhosin. For example, Suhosin's protection against null bytes in inputs were made unnecessary by PHP 5.3.4, which made null bytes in filenames always throw an error rather than silently truncating the filename at the null byte.

Thanks

[scott]

It has some cool functions still, like the unless allow/deny policy for remote urls. It all depends on the environment I suppose

[BruceLee]

Ok.
Btw....this brings me to a question I have not thought about before.
Are suhosin features somehow used/set "automically" by ASL?
I must confess that I use suhosin in a "set and forget" way.

Thanks

[scott]

Indirectly, we have rules in the HIDS that can parse output from suhosin. Those would be used to generate firewall blocks

[BruceLee]

thanks. good to know.