FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-02-2012, 03:19 PM
Ian Jackson
 
Default 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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20266.47010.249265.253602@chiark.greenend.org.uk"> http://lists.debian.org/20266.47010.249265.253602@chiark.greenend.org.uk
 
Old 02-02-2012, 04:59 PM
Stas Malyshev
 
Default 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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F2ACEEB.4080202@sugarcrm.com">http://lists.debian.org/4F2ACEEB.4080202@sugarcrm.com
 
Old 02-02-2012, 05:35 PM
Ángel González
 
Default 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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F2AD757.3070406@gmail.com">http://lists.debian.org/4F2AD757.3070406@gmail.com
 
Old 02-02-2012, 07:11 PM
Thomas Goirand
 
Default 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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F2AEDF8.2010203@debian.org">http://lists.debian.org/4F2AEDF8.2010203@debian.org
 
Old 02-02-2012, 08:56 PM
Carlos Alberto Lopez Perez
 
Default 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 <thoger@redhat.com>
To: OSS Security <oss-security@lists.openwall.com>
Cc: security@php.net, Stefan Esser <stefan.esser@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=revision&revision=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 Engineering http://www.igalia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
 
Old 02-02-2012, 10:26 PM
Russ Allbery
 
Default Suhosin patch disabled by default in Debian php5 builds

Ian Jackson <ijackson@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87fwesq0jz.fsf@windlord.stanford.edu">http://lists.debian.org/87fwesq0jz.fsf@windlord.stanford.edu
 
Old 02-02-2012, 10:45 PM
Russell Coker
 
Default Suhosin patch disabled by default in Debian php5 builds

On Fri, 3 Feb 2012, Russ Allbery <rra@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 Blog http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201202031046.00230.russell@coker.com.au">http://lists.debian.org/201202031046.00230.russell@coker.com.au
 
Old 02-02-2012, 10:47 PM
Russ Allbery
 
Default Suhosin patch disabled by default in Debian php5 builds

Russell Coker <russell@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87wr84ol0r.fsf@windlord.stanford.edu">http://lists.debian.org/87wr84ol0r.fsf@windlord.stanford.edu
 
Old 02-02-2012, 11:28 PM
Christoph Anton Mitterer
 
Default Suhosin patch disabled by default in Debian php5 builds

Hey.

First, thanks Ondřej, for bringing this to a wider audience




On Thu, 2012-02-02 at 13:55 +0100, Ondřej Surý wrote:
> 1. Suhosin patch has an impact on the speed and memory usage. This has
> been documented and even author admits it [1].
>
> 2. It doesn't help our users when reporting bugs to upstream - the
> usual answer is - try if that happens with vanilla php.
>
> 5. Keeping our code close to upstream and to other linux distros
> (Fedora - no, Suse - optional) is a way how to provide our users with
> consistent behaviour across the Linux ecosystem.


I guess these three could be solved by my suggestion of having separate
packages with and without the suhosin core patched applied.
In case of (1), people can just choose. This is just what Stas Malyshev
talked about. Some people may depend on speed/memory... some absolutely
not (just take my little DAViCal server which is responsible for #657698
and this discussion ).

In case of (2), one can ask them to reproduce it first with the
non-suhosin package.


> 3. Stefan's relationships with PHP upstream (and vice versa)[1] isn't
> helping very much - and I think we (pkg-php) have improved our
> relationship with upstream in past few years a lot.

I don't know any details here, but as long as his patched work well on
the vanilla source,... it shouldn't be a major issue for Debian, right?



I agree with Stefan, that having such guards is a good thing. This is to
some extent why things like grsceurity, PaX, and similar exist. There
always was need for them,.. and I guess there allways will be.
Just saying "there were only few security holes recently" is not an
argument. An argument would be "most/all features of suhosin are now
integrated or handled similarly in PHP anyway".
I think that also his argument of the advantage of having such a patch
external is not to stupid,... of course it makes problems in other
corners.

Btw: Stefan, while I understand that you may feel offended that suhosin
it dropped/attacked/criticised, I guess it doesn't help that you use
unfriendly words.
And the same applies to those who did vice versa (to Stefan).


On Thu, 2012-02-02 at 15:26 -0800, Russ Allbery 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.

I don't want to open a discussion about whether SELinux or some other
framwork is THE answer ;-) but I always had the impression that the
blocker here was rather that there is (which is also a good think) no
single dictator in Debian who can really say: All maintainers, listen
up, go an support SELinux in your packages.
(Which RedHat can do).

Apart from that, I fully agree with your arguments.


The reasons why I've opened #657698 was just, because I though it could
be possible for the PHP maintainers to reduce their burden, by just
offering both, packages with suhosin and without.
If there are bugs in the with suhosin version, they can either redirect
people to upstream, or the no suhosin version or even (if time is
available) try to help.

I have however still not understood, whether one would need to compile
the extensions for both versions, Stefan?!




On Fri, 2012-02-03 at 10:45 +1100, Russell Coker wrote:
> 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.

Phew,.. but is it really a good idea to let this be done by innocent
end-users?! I mean this IS just why the critical packages support
SELinux and don't require the the users to do it themselves.
Analogously, this applies to the PHP core packages, IMHO.




On Fri, 2012-02-03 at 04:11 +0800, Thomas Goirand wrote:
> 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.
Absolutely +1 ;-)

But this wouldn't solve our discussion here... the question would still
be open, whether Debian sets this flag or not, or whether it makes two
binary packages.


Cheers,
Chris.
 
Old 02-03-2012, 05:21 AM
Florian Anderiasch
 
Default Suhosin patch disabled by default in Debian php5 builds

On 02/03/2012 01:28 AM, Christoph Anton Mitterer wrote:
> But this wouldn't solve our discussion here... the question would
> still be open, whether Debian sets this flag or not, or whether it
> makes two binary packages.

Now that's something I didn't read from Ondřej's mail, but delivering
the packages with and without suhosin would, while being more work,
certainly the most helpful way for users. Then again I'd gladly help if
there's anything of this additional work that can be done.

I'd prefer to have Debian's default php5 package with Suhosin as usual,
but I'm hardly the one making demands or suggestions here.

I'm with Soenke (different mail in this thread) - better keep the
securest-possible package by default. When I need performance, I'm
rolling my own php anyway - no matter what base system or package format.

Greetings,
Florian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F2B7CFD.4050709@anderiasch.de">http://lists.debian.org/4F2B7CFD.4050709@anderiasch.de
 

Thread Tools




All times are GMT. The time now is 07:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org