Bug 453235 - Add suhosin patch
Add suhosin patch
Status: CLOSED DUPLICATE of bug 250105
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Joe Orton
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-27 23:40 EDT by Rahul Sundaram
Modified: 2013-03-13 01:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-30 03:14:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rahul Sundaram 2008-06-27 23:40:24 EDT
Description of problem:

Suhosin is a patch to the Zend engine that has a history of preventing of
mitigating PHP related exploits. Apparently both Debian and Mandriva are
shipping with these patch by default for sometime now. Any opinions on applying
this for Fedora and RHEL?

References:

http://www.hardened-php.net/suhosin/a_feature_list.html
http://forum.hardened-php.net/viewtopic.php?id=233
http://packages.qa.debian.org/p/php5/news/20070918T141149Z.html
Comment 1 Remi Collet 2008-06-28 01:30:32 EDT
This patch can be included in 2 ways

1/ a patch php binary (which is what Debian provides)

2/ a pecl extension (which is under review : see #426985)

Only the first provides all the security features.

Another question is if it should be enabled on install ?
Comment 2 Rahul Sundaram 2008-06-28 03:04:00 EDT
We probably need to run this through the security team and then enable this by
default if they agree. I am CC'ing Josh Bressers
Comment 3 John Poelstra 2008-06-28 10:59:57 EDT
triaged
Comment 4 Joe Orton 2008-06-30 03:14:26 EDT

*** This bug has been marked as a duplicate of 250105 ***
Comment 5 Josh Bressers 2008-06-30 08:03:44 EDT
I'm personally not very comfortable including a third party patch to our PHP. 
These usually prove to be anchors around your neck when spread out over time.
While PHP has had its share of flaws, none of them are all that bad really.  The
real issue is crappy PHP aplications.  So this raises some questions in my mind.

1) What does Joe think (I'm currently leaning toward add it as a plugin if you
want it)

2) What has this stopped in the past.  It's easy to claim it works, I want to
know what it really does, and what flaws has it stopped.

3) Why isn't this in PHP upstream?

I'm not worried about what other distributions are doing.  The only question we
should ask is "is the work needed to maintain this worth the protection it will
provide".  I don't know the answer to that.
Comment 6 Rahul Sundaram 2008-06-30 08:15:31 EDT
1) The plugin isn't a alternative to the patch. They are meant to be used in
combination with each other.

2) http://www.hardened-php.net/advisories.15.html

3) http://blog.php-security.org/archives/61-Retired-from-securityphp.net.html
Comment 7 Josh Bressers 2008-06-30 09:52:50 EDT
Neither of those links add any value to this bug.  My questions are quite to the
point and are valid concerns regarding this out of band third party patch.
Comment 8 Rahul Sundaram 2008-06-30 10:00:54 EDT
So let me explain again, the advisories in the website forum lists
vulnerabilities and details how the patch mitigates them. The second link talks
about the author of this patch resigning from the PHP security team. The patch
doesn't get upstream due to this politics. Hope that helps.
Comment 9 Josh Bressers 2008-06-30 10:25:47 EDT
From looking over them, the last advisory that mentions Suhosin is from 2006,
none of the 2007 advisories mention Suhosin at all.  Those appear to be
advisories for flaws found by the Hardened PHP project, not for flaws Suhosin
protects against.

If the patch won't go upstream due to politics, why do we want to include it? 
Wouldn't it make more sense to put our effort into getting it upstream rather
than  adding it as a third party add-on?
Comment 10 Rahul Sundaram 2008-06-30 10:33:19 EDT
Yes, that might indeed be the right path forward but I do know understand the
patch enough to comment on how feasible that is. Perhaps the maintainer can talk
to upstream?
Comment 11 Joe Orton 2008-07-02 07:19:48 EDT
Note that the Suhosin extension is independent of the patch and has already been
proposed for inclusion in Fedora, see bug 426985.

My comment in bug 250105 comment 2 stands.  Suhosin does not create a "sandbox"
in which untrusted PHP code can run safely; it doesn't fundamentally change the
PHP security model.  I think that the performance trade-off necessary in trying
to add the canaries etc in Stefan's patch has been explicitly rejected upstream;
so I don't see how my time could be spent on this wisely.
Comment 12 Tim Jackson 2008-07-13 07:30:53 EDT
I agree with Joe; if the patches to PHP source are useful, they should be
applied upstream. I don't think it's our job to make a difficult decision about
this low-level patch, and it will create work maintaining it especially if
upstream is slow updating the patch, the old one doesn't apply against a new
release and we need to get an updated PHP release out for security. Ironically
that could make the security situation worse.

By all means let's have the plugin in bug #426985 but let's not have this patch.

Note You need to log in before you can comment on or make changes to this bug.