Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57686
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nopiracy.de from 81.169.146.161 cause and error)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
In-Reply-To: <CAEZPtU7qyezW44HJbHS=wz5+2_O4PJywg8=Oafhn1JBLonQmwA@mail.gmail.com>
Date: Sat, 4 Feb 2012 10:46:28 +0100
Cc: Stas Malyshev <smalyshev@sugarcrm.com>,
 Soenke Ruempler - Jimdo <soenke@jimdo.com>,
 PHP internals <internals@lists.php.net>,
 "security@php.net" <security@php.net>,
 "zigo@debian.org" <zigo@debian.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <BB9858AE-5AC9-4602-9D6A-2240E0F497AD@nopiracy.de>
References: <CALjhHG_wYvJn-Z+x9fJUi+dgmZ+Ha9BD54N5VwhneJM4sg1xBQ@mail.gmail.com> <5FB5CFDA-6FE8-4C20-A9B9-7844ED96659B@nopiracy.de> <CAEZPtU7jtQTDNpUovxxnDdRunjH9BOdX=WbS8JcGz+5Wkz8ocw@mail.gmail.com> <4F2A9378.70803@thelounge.net> <4F2AC9CA.2070308@sugarcrm.com> <4F2B2ED8.4050900@jimdo.com> <72878E6C-4C17-4D94-9F73-1446769247E1@nopiracy.de> <CAEZPtU5CP3GqUnKsxx51-ieHAdGh=ySvZCWhhAwa0kwuNG6Bhg@mail.gmail.com> <A33C7716-F355-455E-863D-5458205C3208@nopiracy.de> <4F2CEA7E.9010906@sugarcrm.com> <9684A843-5A7F-43BB-BFC2-86F34E27EC3B@nopiracy.de> <CAEZPtU6eYxWM+hL4RzO_Mpx7GgDe3cxJNbZXbwD2MXdFUPS+aA@mail.gmail.com> <A3FA10BF-D660-4705-BBF0-1AF8F9D27C35@nopiracy.de> <CAEZPtU7qyezW44HJbHS=wz5+2_O4PJywg8=Oafhn1JBLonQmwA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Subject: Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
From: stefan@nopiracy.de (Stefan Esser)

Hello Pierre,

>> See you do it again. You claim I believe EMET has been created =
because of Suhosin. I never said that. Although one of the lead =
developers of EMET compared it himself to it.
>> You know some features of Suhosin are already in PHP and the HTTP =
response splitting drama shows that when you break it there is a =
secondary layer of defense that protects you in case you use Suhosin.
>=20
> I was talking about the compilation security options which are similar
> (in some extends) to what Suhosin does (for some features).

Actually no. The key security iprovements in Suhosin-Patch have nothing =
todo with anything the compile time options of VC offer.
Suhosin does not attempt to do Stack Protection, or ASLR or NX. The only =
thing that might be a compile time option is support for %n in format =
strings. I think VC or libs do not allow that anymore.
The problem with PHP is that is does a lot of things like implementing =
their own heap manager from scratch, which is a security nightmare and =
something a compiler cannot protect you from.


>> Do you forget PHP 5.3.7 and PHP 5.3.9 both times there were security =
vulnerabilities introduced right after the last RC.
>> This is a sign that the PHP development process is still not healthy =
at all.

> So any software having security issues at one point or another is not =
healthy?
Again. We are not talking about software having security issues. We are =
talking about software with 4,5 or whatever number of release =
candidates.
And then the security vulnerability is caused by an unreviewed commit to =
the code after the last release candidate and before final.

This is bad. And there is no point arguing this fact.


> I consider the opposite, I am very careful when I see a software
> without any discovered issues for a long time, a sign of lack of
> activities and users.
Of course it might mean exactly this. But it could also mean that the =
software simply works and does not have major problems.


>> You claim I have personal issues, while I repeatedly tell you the =
technical reasons why I see it different then you.
>=20
> Sorry but I do not see technical issues in this thread, as in
> technical explanations about why one given feature is actually a good
> thing. I did not see any either in the past discussions.

I repeatedly tell you that a second layer of defense outside of the main =
product is a good thing.
You disagree. However defense in depth is widely accepted as the way to =
go.

Also having canaries in memory managers, while using more memory is a =
known valid mitigation against buffer overflows. You can look it up on =
the internet.
Having pointer obfuscation is also a mitigation you see in glibc and =
Microsoft (even in Internet Explorer).
Whitelisting of destructors is a mitigation based on whitelisting.

These are all basic prinicples of security mitigations. Why is there a =
need to write up RFC about these things. They are widely accepted by =
other software vendors/products.

Regards,
Stefan=