To suhosin or not to suhosin, PHP 5.4 IS the question.

[jols]

Hi,

I am in the process of configuring a new server. I notice that PHP 5.4.x is now available in easyapache (no longer experimental). That's cool, but as I read here and elsewhere suhosin is not compatible with this new version of PHP.

So, what's a poor boy to do?

It seems that at least some of the suhosin protections are built into PHP, e.g. an overall memory limit that a single process can take, and so on. But I do like the input character limit that you can specify with suhosin, and probably tons of other stuff that I have never really looked at.

On the other hand, I do believe that PHP 5.4 is relatively compatible with scripts that can run well under PHP 5.3.x, and I also understand that it is more secure and more stable than PHP 5.3.x as well.

So..... do I drop the idea of using the suhosin, PHP hardening protections in favor of PHP 5.4.x, or do I wait until suhosin is compatible with this newer PHP version?

I suppose this could be an informal survey of sorts... What would YOU do in my situation?

Thanks much.

 

[aww]

Just keep using 5.3 until it's EOL and hope someone eventually updates Suhosin.

Suhosin adds many other subtle protections.

 

[jols]

Grunk! Thanks very much for the response.

I have no idea why the PHP Product Group does not include at least some Suhosin's ever-so-logical protections into their main framework. Apparently last April there was some activity in this regard, in making Suhosin compatible with PHP 5.4.x. See:

Upgrade woes III: Suhosin and PHP 5.4.0 - Dr. Christopher Kunz

But from the looks of it, the project is pretty dormant at this time while the one, sole, solitary developer went off to write a book. I guess you get what you pay for, even if comes to the entire dang world wide PHP system, and even Linux itself.

 

[aww]

PHP unfortunately suffers from internal politics with just a few people making dramatic course changes and arbitrary decisions that affect thousands.

They don't seem to have gotten along with the suhosin author despite his important contributions so that probably doomed suhosin.

 

[jols]

Sorry to see this, perhaps cPanel.net should (continue to?) pick up the slack, seeing as how the grand majority of their installations depend on PHP functioning security.

 

[WhiteDog]

It seems there is a version of suhosin available that is compatible with PHP 5.4:
Upgrade woes III: Suhosin and PHP 5.4.0 - Dr. Christopher Kunz

I assume it is up to cPanel (Easyapache team?) to implement this?

 

[jols]

Same link I found. Problem is apparently, there's been no development work on this since - Mar 21 2012. I hope this does not mean the project is dead.

All in all I think it's downright silly that every cPanel server running PHP is dependent on this (Achilles heel?) for solid PHP security.

 

[WhiteDog]

Well don't worry just yet. I upgraded to PHP 5.4.10 yesterday and quickly reverted back to 5.3.20
PHP 5.4.x is definetly not ready yet for shared hosting environments. Stuff will break.

 

[jols]

Any movement on this yet? Anyone?

 

[LeadDogGraphics]

Any movement on this yet? Anyone?

Check the suhosin dev page: https://github.com/stefanesser/suhosin

So far no movement in almost a year.

 

[jols]

It's amazing the PHP development group (or cPanel.net) has yet to incorporate the very logical protections that suhosin implements, especially considering the bazillions of servers that use PHP these days.

 

[jols]

Interesting thread here:
https://pierre-schmitz.com/php-5-4-1-in-suhosin-out/

 

[georgeb]

Hi,
I suppose this could be an informal survey of sorts... What would YOU do in my situation?
Thanks much.

I am using in production servers PHP 5.4.11 with no problem. There was one problem because the new PHP 5.4.11 the E_STRICT is included in E_ALL. So after some test it is OK. No complains yet.

Regards,
George B.

 

[LeadDogGraphics]

My opinion is Suhosin is dead, move on or join in and contribute development to it. The rest of us have moved on, use kernel level security such as GRSec since it's updated every few days.

 

[cPanelJamyn]

It's amazing the PHP development group (or cPanel.net) has yet to incorporate the very logical protections that suhosin implements, especially considering the bazillions of servers that use PHP these days.

Hi,

I can appreciate that concern. However, we don't typically re-distribute unversioned software. The Suhosin developer has not released any official version with PHP 5.4 support. As LeadDogGraphics mentioned, the developer has not updated Suhosin in quite some time, yet he is against letting the PHP team incorporate Suhosin into PHP itself. Essentially, he's not maintaining it, and appears to be against letting anyone else do so.


Suhosin continues to work with all prior PHP versions (ex: PHP 5.3), yet we are also aware that PHP 5.3 is officially EOL next month. This puts us in an interesting position.

Rather than release a 'bleeding edge' version of Suhosin, we've been waiting for a formal release. I encourage you to file a feature request if PHP 5.4 Suhosin support is important to you, as we have limited resources and have to carefully choose where to spend development time. Thanks!

 

[jols]

Understood and appreciated. And I do not mean to be crass or flip in any way, but with the grand majority of cPanel systems using PHP, the "interesting position" you site looks like a bit of a brick wall.

I can only speak from experience. We also have to carefully choose where to spend development time.... EXCEPT, when it comes to security matters. In this area, all the development time we've invested over the past 14 years can be nullified in less than 15 minutes if security is not there.

When we see that our servers could be compromised if we don't act.... For us it's all-hands-on-deck around the clock until the issue is fully resolved.

Yes, I know that cPanel.net puts high priority in keeping their system as security tight as possible. I've seen this plenty of times in the past, and I've always appreciated that. I would only ask, and I do sincerely hope, that they carry on in this same manner with regard to this growing concern.

 

[cPanelJamyn]

Understood and appreciated. And I do not mean to be crass or flip in any way, but with the grand majority of cPanel systems using PHP, the "interesting position" you site looks like a bit of a brick wall.

I can only speak from experience. We also have to carefully choose where to spend development time.... EXCEPT, when it comes to security matters. In this area, all the development time we've invested over the past 14 years can be nullified in less than 15 minutes if security is not there.

Agreed. The issue is not that we're unwilling to submit fixes and patches upstream as we find problems. The reason it's an interesting position for us is because we are re-distributing a third party product (Suhosin), and it's not code we develop in-house. The author appears to have abandoned the project (or at least is spending his time elsewhere at the moment). Essentially, I presume the decision would be whether to fork or maintain Suhosin in-house if the author stops updating it. That's a big commitment, especially since it's a public project with a reasonably large userbase across many platforms.

In any event, we are certainly evaluating the situation, and I really do appreciate the feedback. Thanks!

 

[jols]

I understand with regard to picking this up in the form of a public project. That's not quite the point. What I was hoping for is that cPanel.net close some of the gaps left behind by a non-security-hardened PHP, by including a new set of custom protections, i.e. just for cPanel users.

Now I DO also understand what a technical challenge it would be to offer a series of input filters that stand in between Apache and the PHP interpreter. However it seems to me that any results in this regard would also increase cPanel.net's product value in the marketplace, especially considering Suhosin's demise.

That said, I certainly commend cPanel.net for their partnership with CloudLinux, which will not quite achieve the aforementioned results, but nevertheless is, in my view, a step in the right direction.

 

[cPanelJamyn]

<snip> What I was hoping for is that cPanel.net close some of the gaps left behind by a non-security-hardened PHP, by including a new set of custom protections, i.e. just for cPanel users.<snip>

I think you've raised a number of valid points. I'll certainly add this to the internal EA discussion items so we can throw some ideas around. Thank you.

 

[jols]

Good. And hey, while you are at it, please have them finally give us the option in WHM to nix the "Unlimited" setting for email accounts.

I know this is OT, but it has been a humongous pain in the ars over the years, dealing with hosting accounts that should only be 200mb, but end up being 200GB due to massive multi-Gigabyte email accounts that have just sat dormant over the years accumulating an UNLIMITED amount of useless email garbage.

No big technical calculation needed for this. Just give host admins the ability NOT to blatantly invite such issues by including the Unlimited option with every email account on the server, i.e. so at least the email account owners will be forced to type in the exact quota setting rather than setting Unlimited and then forgetting about it..... for months, years, decades..... you name it.

Such a thing has been long promised by cPanel.net and is now long, long overdue. (Yes, I've suggested this feature per the official channels for doing so, but after years... so far no good.)

We fight with this several times per week here lately. And no, I don't want to start cloning then modifying templates, then missing the regular cPanel updates to these as a result.

Sorry for the rant.