Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hi John, Ondřej (One of the Debian PHP maintainers) listed 5 or 6 reasons in the initial email in this thread. Honestly, I can't think of a good reason for Debian or anyone else to include 3rd party patches, whatever the patches purpose, in the default PHP packages. I would argue that, if people want 3rd party patches they should either: A) Apply the patch themselves. or: B) Petition the author and php-core to have the patch applied upstream, to everyone's benefit. This is the only way to ensure IMO that everyone is using the same PHP, or they have explicitly opted to use some 3rd party code. Thanks, Kiall On Sat, Feb 4, 2012 at 5:21 PM, John Crenshaw johncrens...@priacta.comwrote: OK, All the mud slinging is getting really silly (on *both* sides). There's no need to denigrate others because you don't agree with them. There's no point in arguing about who isn't a team player or who works for which evil multinational corporation. Nobody is attacking anybody else by suggesting that Suhosin is or is not critical, and none of that really matters anyway. I may have missed something, but has anyone asked *why* the patch was disabled? I think I could make a good guess, but I haven't seen even the slightest hint of the actual reasons in this email chain (though I could easily have missed it entirely). IMO we should try to focus on: 1. What are the pros vs. cons of enabling the Suhosin patch by default? 2. Why did the Debian team opt to disable it? 3. Are there better solutions that should be considered and recommended? John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Ondřej, My personal feeling is that most people see suhosin as this is about security, thus it must be good. This combined with bad PHP security history makes everybody feel insecure when suhosin was removed, but the real question is if the suhosin is still really helping with PHP security or it is just a burden in the general installations now. considering the fact that you write this email the very same day that a remote code execution vulnerability in PHP is found that is easy to exploit from remote and is greatly mitigated by the use of Suhosin you look pretty stupid. (In case of usage of Suhosin-Extension in default config, it is even completely killed). Just saying. Regards, Stefan Esser -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hi Stefan, On Thu, Feb 2, 2012 at 2:31 PM, Stefan Esser ste...@nopiracy.de wrote: Hello Ondřej, My personal feeling is that most people see suhosin as this is about security, thus it must be good. This combined with bad PHP security history makes everybody feel insecure when suhosin was removed, but the real question is if the suhosin is still really helping with PHP security or it is just a burden in the general installations now. considering the fact that you write this email the very same day that a remote code execution vulnerability in PHP is found that is easy to exploit from remote and is greatly mitigated by the use of Suhosin you look pretty stupid. (In case of usage of Suhosin-Extension in default config, it is even completely killed). Another very important part of Ondrej's email was: Please keep the discussion civil and on the technical level And at this point, I may suggest you to keep such posts for yourself. About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and will have bugs. This is not really hot news. That does not affect this discussion. I, for one, like the idea to finally see distros droping Suhosin and focus on making PHP itself better and safer instead of distracting us and our users with custom patches or extensions. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
On 02/02/12 14:31, Stefan Esser wrote: considering the fact that you write this email the very same day that a remote code execution vulnerability in PHP is found that is easy to exploit from remote and is greatly mitigated by the use of Suhosin you look pretty stupid. (In case of usage of Suhosin-Extension in default config, it is even completely killed). Just saying. I think that you words are out of tone, there is not need to be unpolite And where is such exploit??? I don't see any CVE http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74 -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Pierre, About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and will have bugs. This is not really hot news. That does not affect this discussion. I know that for many years you have not understood the idea behind Suhosin, the concept of exploit mitigations. The only reason why Suhosin exists is because there will ALWAYS be bugs. And because that is a fact you must have safe guards in case something goes wrong. Suhosin/HPHP provides this safe guard for 8 years to the PHP community. Ideas like: I haven't seen much bugs lately so lets drop all the safe guards is like not paying for your life insurance anymore, because you haven't died too often recently. BTW: You should really really look into the history of PHP security and check for each of the last 8 years how many features were in Suhosin and later merged into PHP because of some nasty security problem. You will see that at least 2 features of Suhosin per year were merged into PHP. And there are many many good reasons, why Suhosin must be external to PHP. The most obvious one is that the code is clearly separated, so that not someone of the hundred PHP commiters accidently breaks a safe guard. Regards, Stefan Esser -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Ohh btw… I have walked the bug list for 5.3 mentioning suhosin[2] to actually at least partially support what I have just said. I have found few bugs where suhosin was causing a problems ([3],[4]) and a handful of bugs with have suhosin, cannot help. I know this isn't (and can't be) a definitive list, but it just show that P.S.: Also see stas reply[5] about valgrind. Links: 1. http://www.hardened-php.net/hphp/faq.html#why_is_hardening-patch_not_part_of_php 2. https://bugs.php.net/search.php?search_for=suhosinboolean=0limit=90order_by=direction=DESCcmd=displaystatus=Allbug_type=Allproject=PHPphp_os=phpver=5.3cve_id=assign=author_email=bug_age=0bug_updated=0 3. https://bugs.php.net/bug.php?id=60216 4. https://bugs.php.net/bug.php?id=60935 5. http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/ 1) You understand that Hardening-Patch is not Suhosin-Patch, do you? 2) Maybe you should also search for: Have Debian, then use a clean PHP not a broken Debian build Bug 3 - is not a bug in Suhosin, it is the fact that the suhosin.executor.max_depth function was not set correctly. Reading the documentation helps: http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.max_depth Bug 4 - the guy is actually writing inside the bug report that the problem occurs with and without Suhosin 5) You can just start PHP with the environment variable SUHOSIN_MM_USE_CANARY_PROTECTION=0 and can use valgrind. So basically all points you bring up are no issues. Regards, Stefan Esser -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
On Thu, Feb 02, 2012 at 03:14:56PM +0100, Stefan Esser wrote: BTW: You should really really look into the history of PHP security and check for each of the last 8 years how many features were in Suhosin and later merged into PHP because of some nasty security problem. You will see that at least 2 features of Suhosin per year were merged into PHP. If that’s the case, then you have nothing to worry about. As more and more Suoshin features are merged into mainline PHP, Debian’s PHP package will get more and more secure. That’s the way it happens for many other packages, I fail to see why PHP should be treated differently. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
hi Stefan, On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser ste...@nopiracy.de wrote: Hello Pierre, About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and will have bugs. This is not really hot news. That does not affect this discussion. I know that for many years you have not understood the idea behind Suhosin, the concept of exploit mitigations. Let me disagree with your way of doing things without telling me that I do not understand what you do. It is two different concepts. I also perfectly understand the goals of Suhosin, the technical as well as the non technical ones. The anonymity of a project is not always helpful. The only reason why Suhosin exists is because there will ALWAYS be bugs. Indeed, so it is for Suhosin as well. BTW: You should really really look into the history of PHP security and check for each of the last 8 years how many features were in Suhosin and later merged into PHP because of some nasty security problem. You will see that at least 2 features of Suhosin per year were merged into PHP. For one, some were not not ported but features were implemented, with the support of their original authors. They are not related to Suhosin, like the Blowfish support, which I ported to php with the help of Solar Designer. Suhosin uses the same implementation. And there are many many good reasons, why Suhosin must be external to PHP. The most obvious one is that the code is clearly separated, so that not someone of the hundred PHP commiters accidently breaks a safe guard. I would be the happiest man on Earth if PHP would have hundred active PHP contributors. As a matter of fact, we have like 3-4 active weekly, less than 10 yearly and maybe around 15 for the 'let commit something' area. While we discuss about the reasons why I do not think Suhosin is not the right way, let start from the beginning. I understand why you left the security team and the php project years ago. Back then I was not on the security team, so I won't comment this period (and I would have partially agreed with you). However, I am part of this team since some years now and I (along with other) have been pushing drastic changes in the way we work, for releases or security issues in particular. You are ignoring these changes and progresses. For example the Release RFC (https://wiki.php.net/rfc/releaseprocess): . does not allow new features after x.y.0 final . enforce quick release when a flaw is discovered much easier to do as no noise commits will be present . many other good things Only the two first points will drastically increase the quality and safety of our releases. The reason is that the amount of unnecessary commits will be null, or almost null. That kills the argument about 'hundred of commit(ers) breaking PHP'. It also helps to get fixes out sooner rather than later. Many features are making their way to PHP as well, on a case by case basis. We have changed and we are on the right track since quite some time already. If you have features that you consider that it must be in the core, then let discuss it, on this list. But so far I failed to see other features in Suhosin that we need to implement without having more cons than pros. I am also convinced that these new policies will also allow distributions to update to the latest release of a given branches instead of having to backport fixes to their tree. And that alone is a huge step forward. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
On Thu, Feb 2, 2012 at 4:49 PM, Pierre Joye pierre@gmail.com wrote: hi Stefan, On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser ste...@nopiracy.de wrote: Hello Pierre, About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and will have bugs. This is not really hot news. That does not affect this discussion. I know that for many years you have not understood the idea behind Suhosin, the concept of exploit mitigations. Let me disagree with your way of doing things without telling me that I do not understand what you do. It is two different concepts. I also perfectly understand the goals of Suhosin, the technical as well as the non technical ones. The anonymity of a project is not always helpful. The only reason why Suhosin exists is because there will ALWAYS be bugs. Indeed, so it is for Suhosin as well. BTW: You should really really look into the history of PHP security and check for each of the last 8 years how many features were in Suhosin and later merged into PHP because of some nasty security problem. You will see that at least 2 features of Suhosin per year were merged into PHP. For one, some were not not ported but features were implemented, with the support of their original authors. They are not related to Suhosin, like the Blowfish support, which I ported to php with the help of Solar Designer. Suhosin uses the same implementation. And there are many many good reasons, why Suhosin must be external to PHP. The most obvious one is that the code is clearly separated, so that not someone of the hundred PHP commiters accidently breaks a safe guard. I would be the happiest man on Earth if PHP would have hundred active PHP contributors. As a matter of fact, we have like 3-4 active weekly, less than 10 yearly and maybe around 15 for the 'let commit something' area. While we discuss about the reasons why I do not think Suhosin is not the right way, let start from the beginning. I understand why you left the security team and the php project years ago. Back then I was not on the security team, so I won't comment this period (and I would have partially agreed with you). However, I am part of this team since some years now and I (along with other) have been pushing drastic changes in the way we work, for releases or security issues in particular. You are ignoring these changes and progresses. For example the Release RFC (https://wiki.php.net/rfc/releaseprocess): . does not allow new features after x.y.0 final . enforce quick release when a flaw is discovered much easier to do as no noise commits will be present . many other good things Only the two first points will drastically increase the quality and safety of our releases. The reason is that the amount of unnecessary commits will be null, or almost null. That kills the argument about 'hundred of commit(ers) breaking PHP'. It also helps to get fixes out sooner rather than later. Many features are making their way to PHP as well, on a case by case basis. We have changed and we are on the right track since quite some time already. If you have features that you consider that it must be in the core, then let discuss it, on this list. But so far I failed to see other features in Suhosin that we need to implement without having more cons than pros. I am also convinced that these new policies will also allow distributions to update to the latest release of a given branches instead of having to backport fixes to their tree. And that alone is a huge step forward. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php In fact, I agree that it'd be a good idea to discuss more widely PHP Security , why not through specific RFCs, with POCs of each ideas/concepts , so that people could comment on them, and approve/decline the concepts/patches :) Julien.P
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
[resent with 7-bit headers. apologies for any mangled names:] Pierre Joye writes (Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds): [...] But so far I failed to see other features in Suhosin that we need to implement without having more cons than pros. I know nearly nothing about PHP security and nothing about Suhosin. But from what I have read in this thread, I find this kind of argument very unconvincing. Surely the time to drop something like Suhosin would be when PHP stops actually having bugs which are mitigated by Suhosin. Not when the PHP project claims to have improved its processes so that these bugs won't occur any more. The decision should be based on the existence or not of the vulnerabilities, and whether Suhosin in actual fact helps. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hi! I know that for many years you have not understood the idea behind Suhosin, the concept of exploit mitigations. I think we have a difference of approaches here, and it is well known. There's more or less a consensus among PHP dev that to introduce a feature, especially with high user performance cost and other risks, into PHP its necessity to the user needs to be proven and outweigh the problems it causes. You seem to advocate the approach in which performance and convenience can and should be sacrificed to security. It is a matter of opinion, and each one has its own validity. We probably would have for now to agree to disagree here. That said, I personally would be happy to see more participation from you - including and especially contributing and maintaining parts of Suhosin patch that do not have high costs and user issues associated with them and are not controversial - I think it would benefit PHP a lot. Of course, it's your decision, but I think that would be better both for PHP security and PHP users which have little interest in what belongs where and why, but right now the only person who can maintain and support any line of code in Suhosin is you, which is not always helpful to the users. The most obvious one is that the code is clearly separated, so that not someone of the hundred PHP commiters accidently breaks a safe guard. There's no hundred PHP committers except in theory. In practice, number of people regularly committing to relevant part of the core is probably less then 10. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Stefan Esser wrote: And there are many many good reasons, why Suhosin must be external to PHP. The most obvious one is that the code is clearly separated, so that not someone of the hundred PHP commiters accidently breaks a safe guard. That's not a justification to keep it as a patch. Safe guards could prefectly be skipped by a commit which changed near code, reestructures the function or creates a different path, *even if the patch still applies*. So you would still need to check for all kind of unexpected changes anyway. If it were in core, at least anyone changing the related code would realise that it's there, and could take that into account for not breaking it. If it's maintained by someone else as a patch, that simply won't happen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
On 02/03/2012 01:59 AM, Stas Malyshev wrote: You seem to advocate the approach in which performance and convenience can and should be sacrificed to security. It is a matter of opinion Something I don't get here. If there's this issue, and different tastes, why can't a build flag be used, so that you can choose security or speed depending on your needs? If you do some: #ifdef ENABLE_SLOWER_SUHOSIN_SECURITY in the controversial parts, then I don't see how this would be of trouble for anyone to have Suhosin included in upstream PHP. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
On 02/02/12 14:43, Carlos Alberto Lopez Perez wrote: On 02/02/12 14:31, Stefan Esser wrote: considering the fact that you write this email the very same day that a remote code execution vulnerability in PHP is found that is easy to exploit from remote and is greatly mitigated by the use of Suhosin you look pretty stupid. (In case of usage of Suhosin-Extension in default config, it is even completely killed). Just saying. I think that you words are out of tone, there is not need to be unpolite And where is such exploit??? I don't see any CVE Answering myself: Original Message From: Tomas Hoger tho...@redhat.com To: OSS Security oss-secur...@lists.openwall.com Cc: secur...@php.net, Stefan Esser stefan.es...@sektioneins.de Subject: [oss-security] PHP remote code execution introduced via HashDoS fix Hi! Internets are buzzing with info on the PHP flaw found by Stefan Esser in the fix for CVE-2011-4885. http://thexploit.com/sec/critical-php-remote-vulnerability-introduced-in-fix-for-php-hashtable-collision-dos/ http://www.h-online.com/security/news/item/Critical-PHP-vulnerability-being-fixed-1427316.html http://svn.php.net/viewvc?view=revisionrevision=323007 This got CVE-2012-0830 assigned earlier today. This is sent to make the assignment public and avoid possible duplicate assignment. -- Tomas Hoger / Red Hat Security Response Team -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Ian Jackson ijack...@chiark.greenend.org.uk writes: Pierre Joye writes: [...] But so far I failed to see other features in Suhosin that we need to implement without having more cons than pros. I know nearly nothing about PHP security and nothing about Suhosin. But from what I have read in this thread, I find this kind of argument very unconvincing. Surely the time to drop something like Suhosin would be when PHP stops actually having bugs which are mitigated by Suhosin. Not when the PHP project claims to have improved its processes so that these bugs won't occur any more. The decision should be based on the existence or not of the vulnerabilities, and whether Suhosin in actual fact helps. Well, from the Debian perspective, it also needs to be based on the maintainability of the patch and on the benefit versus complexity tradeoff. For example, Debian could immediately become a much more secure OS by enabling SELinux in enforcing mode on all Debian systems. The reason why we don't do this is that currently that tradeoff doesn't make sense; too much other stuff doesn't work, too much other effort is required, and we're not in a position to enforce that technology, even if it would increase security. I think the maintainers need to make a judgement call about whether the problems and additional work required to maintain packages with the patch integrated, for both the Debian maintainers and the PHP user community on Debian, is justified by the benefits provided by the patch. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Russell Coker russ...@coker.com.au writes: SE Linux is supported in critical packages including the kernel, sysvinit, and cron. So any user who wants to use it can just install the SE Linux specific packages and rely on the built-in support for SE Linux in important base packages. This compares to the PHP/Suhosin situation where users who want that have no option other than to download the source and the Suhosin patch and build their own packages. For the analogy you want to make a better option would be GR Security which is not supported in the Debian kernel and won't be supported in the forseeable future. Good point, thank you. That's a better analogy. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
On Fri, 3 Feb 2012, Russ Allbery r...@debian.org wrote: For example, Debian could immediately become a much more secure OS by enabling SELinux in enforcing mode on all Debian systems. The reason why we don't do this is that currently that tradeoff doesn't make sense; too much other stuff doesn't work, too much other effort is required, and we're not in a position to enforce that technology, even if it would increase security. SE Linux is supported in critical packages including the kernel, sysvinit, and cron. So any user who wants to use it can just install the SE Linux specific packages and rely on the built-in support for SE Linux in important base packages. This compares to the PHP/Suhosin situation where users who want that have no option other than to download the source and the Suhosin patch and build their own packages. For the analogy you want to make a better option would be GR Security which is not supported in the Debian kernel and won't be supported in the forseeable future. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
