Wheezy Still Missing Php5-suhosin


I’m working on a server replacement, the old (current) server is running latest stable release and the new server is running from this downloaded installer ISO:


Now, php5-suhosin provides some real protection against programming problems that could very easily exist and it is not uncommon to see messages from Debian stable installs reporting bugs / vulnerabilities detected by suhosin….

It seems to me that this is an essential package for most servers running PHP5 and it’s non-availability is a very serious concern.

I’ve found the following:


Will php5-suhosin be re-instated any time soon? And if not, what measures can we take to protect Wheezy servers now?

Thanks AndrewM

, ,

  1. #1 by “Morel BĂ©renger” on April 10th, 2013 - 6:55 am

    Le Mer 10 avril 2013 12:36, Andrew McGlashan a

  2. #2 by Joe on April 11th, 2013 - 3:11 am

    A working commercial PHP programmer probably could, but I’m not sure it would help. PHP is a programming language, running on a web server, which needs to access the server’s databases, drives, memory etc. There’s no way it can be made secure, any more than C++ could be redesigned to prevent programmers making off-by-one errors, for example. The sword either has two edges or none.

    Early PHP implementations had insecure features for lazy programmers, for example allowing HTTP form parameters to be used directly as variables in programs, rather than obtaining their values and checking them before storing the checked and interpreted values in program variables. Because so much software uses this very dangerous ‘feature’, it must be retained, but it is normally disabled by default. Suhosin, among many other things, will warn about this feature being enabled, or turn it off if so configured. Later and later versions of PHP have become much stricter in many ways, and have offered features like Perl’s optional variable discipline, so many of the Suhosin features are no longer required. Not only that, but Suhosin will warn about things which are now (mostly) safe to do.

    It’s not so much that PHP itself is a problem, but that PHP software on public web servers is completely exposed to any and every kind of attack, and that programmers need to be extremely disciplined to write secure code. You can assist with this kind of discipline in writing a programming language, but you can’t enforce it. If the group of PHP
    programmers for a particular web server were to read the Suhosin specification, and write all their code so as not to activate any of its protections, then that in itelf would help enormously in securing the server. Having Suhosin actually installed will also catch their mistakes. But as stated, Suhosin has not been well maintained and many of its features have become subsumed into PHP itself or have become actively irritating or obstructive, so currently in Wheezy it is seen as more of a liability than an asset. It was dropped from Sid long ago, of course, before Wheezy had frozen, but then you wouldn’t run a public web server on Sid.

  3. #3 by Andrew McGlashan on April 11th, 2013 - 12:57 pm

    If data is passed via forms or via GET or POST and that data isn’t properly handled by php itself, then it may produce a buffer overrun situation … possibly before the data gets passed through to the webpage code; if this can be fixed by an extension or hardening patch, then great, if not, then we are in trouble. Once data gets past php handling and into variables, it becomes the programmer’s responsibility to validate the inputs and make sure that there is no data injection or other misuse issue.


    I would like to know that everything that was providing protection via Suhosin has been incorporated into PHP core, that would be the most logical way to deal with the problem, rather than having 3rd party patches and extensions.

    Actually it does appear to still be in SID:


    Thanks AndrewM

  4. #4 by Joe on April 11th, 2013 - 2:06 pm

    That would indeed be a PHP bug, and would be found quickly. Some people do little else with their lives but fling random data at public interfaces to see what sticks…

    I would doubt that all of it has been. I think it was withdrawn because it became difficult to use.

    OK, I’ve just found this, which will probably answer some of your questions:

    I hadn’t noticed before, but the Debian packages pages show only depends and not conflicts. If you check the properties of php5-suhosin in the Sid apt system you will find it conflicts with php5-suhosin. No, I don’t know why it hasn’t been removed from the distribution, I just remember it being impossible to upgrade some time ago, and after leaving it for a few weeks for the dust to settle, it was still uninstallable.

    I should make clear that I’m not a commercial programmer of any kind, and I dabble in PHP now and then only on my home server. I’m past the ‘a little knowledge’ stage: I know enough about web application security to know that I don’t know anything like enough to write secure code to present to the public, so I don’t attempt it. My home web server is not accessible from outside other than via a certificate-secured VPN.

  5. #5 by Chris Bannister on April 12th, 2013 - 1:40 am

    What does “optional variable discipline” mean?

    I think that would be the case whether the code was perl also, but I’ve only heard bad things about PHP and good things about Perl.

    Does PHP (without any additions) have an equivalent of perl’s “use strict”?

(will not be published)
Subscribe to comments feed