Suhosin patch disabled by default in Debian php5 builds

13 years ago by Stefan Esser — view source — reply

unread

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

13 years ago by Pierre Joye — view source — reply

unread

Hi Stefan,

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

13 years ago by Reindl Harald — view source — reply

unread

Am 02.02.2012 14:38, schrieb Pierre Joye:

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.

yes, but suhosin-extension and hardening patch exists since many years

the question from a normal user:
why are these things not included in the core?

especially the option to disable function by directory while
"disable_functions" is stupidity shown in phpinfo() per dir
but never active?

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

yes, but suhosin-extension and hardening patch exists since many years

the question from a normal user:
why are these things not included in the core?

Because some of these things slow down the code and thus may not be
beneficial to the most users.

especially the option to disable function by directory while
"disable_functions" is stupidity shown in phpinfo() per dir
but never active?

With this feature this may not be a problem, however (I don't know,
didn't look into the actual code). But somebody has to propose it for
inclusion into the core and lead it - i.e. answer questions, participate
in the discussion, change/maintain the patches, etc. If this happens, I
don't see why some of the features can't be brought into code.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Reindl Harald — view source — reply

unread

Am 02.02.2012 18:37, schrieb Stas Malyshev:

yes, but suhosin-extension and hardening patch exists since many years

the question from a normal user:
why are these things not included in the core?

Because some of these things slow down the code

we are using suhosin patch and extension since
years on 5 VMware-Guests on the same host for
500 domains and even running one of them a site
with many hundret active sessions was not a
single performance problem

without bytecode-cache you have much more problems

thus may not be beneficial to the most users

security is not beneficial to the most users?

security is THE benefit for ALL users, especially in days where many
are running crap-code like Joomla/Wordpress with all sorts of plugins
throwing millions of warning if you run with E_ALL and E_STRCIT

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

with many hundret active sessions was not a
single performance problem

I'm not sure I understand what you are talking about here. Performance
is a scale, not a trigger. If you lose 10% (totally invented number as
an example) that doesn't mean you have 10 of "performance problems", it
means you sites run 10% slower, you need 10% more servers, etc.

without bytecode-cache you have much more problems

What bytecode cache has to do with it? Sounds like a non-sequitur.

thus may not be beneficial to the most users

security is not beneficial to the most users?

Please don't do that. I never said that security is not beneficial, and
as you quoted me you know that and you know that "not beneficial"
related to the performance hit the mitigation measures cost.

security is THE benefit for ALL users, especially in days where many
are running crap-code like Joomla/Wordpress with all sorts of plugins
throwing millions of warning if you run with E_ALL and E_STRCIT

What the quality of the code of Joomla has to do with anything? Suhosin
patches would not fix Joomla and most of the issues it helps with are
totally unrelated to any user code at all.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Reindl Harald — view source — reply

unread

Am 02.02.2012 19:02, schrieb Stas Malyshev:

Hi!

with many hundret active sessions was not a
single performance problem

I'm not sure I understand what you are talking about here. Performance is a scale,
not a trigger. If you lose 10% (totally invented number as an example) that doesn't
mean you have 10 of "performance problems", it means you sites run 10% slower, you
need 10% more servers, etc.

as long the cms generates a whole dynamic page from before the
first library include until the genereated page is ready in
0.014 seconds while you have some hundret active users including
an ajax check and having suhosin enabled at this time where
is a SINGLE reason to degrade security by default?

for people running on a 10 year old machine fast but unsecure?
what the hell - on a public sever security is the first and
most important topic and LONG after that performance is one

without bytecode-cache you have much more problems
What bytecode cache has to do with it? Sounds like a non-sequitur.

overall performance

i look at the performance of the whole machine and not a single
part because the single part does not matter if it leads to
successful exploits at last and your whole server is down
and owned - what benefit had you after such things happened
because it was a little faster?

security is not beneficial to the most users?

Please don't do that. I never said that security is not beneficial, and as you quoted
me you know that and you know that "not beneficial" related to the performance hit
the mitigation measures cost.

performance comes in the priority LONG after security
so this is nothing to discuss

security is THE benefit for ALL users, especially in days where many
are running crap-code like Joomla/Wordpress with all sorts of plugins
throwing millions of warning if you run with E_ALL and E_STRCIT

What the quality of the code of Joomla has to do with anything? Suhosin patches
would not fix Joomla and most of the issues it helps with are totally unrelated
to any user code at all.

if code is blowing out millions of warnings it is poorly written code
and poorly written code is ALWAYS a security problem

look at the logs how many bad inputs suhosin is dropping
mostly of them are attacks

if someone attacks your machine EVERY piece increasing security will
make the rsik of a successful intrusion lower, and yes EVERY server
is attacked, every day and every night as long it has a public IP

13 years ago by Tomas Kuliavas — view source — reply

unread

2012.02.02 19:42 Reindl Harald rašė:

security is THE benefit for ALL users, especially in days where many
are running crap-code like Joomla/Wordpress with all sorts of plugins
throwing millions of warning if you run with E_ALL and E_STRCIT

E_STRICT throws notices on properly written code. It contains coding
recommendations that are not compatible with older PHP and code has to
choose between losing backwards compatibility or suppressing those
notices. In some PHP versions suppressing of E_STRICT will also suppress
fatal errors caused by buggy interpreter.

Latest PHP with deprecation notices in E_ALL also throws lots of shit
which does not apply to version you are running.

--
Tomas

13 years ago by Pierre Joye — view source — reply

unread

This is off topic, can we stay on focus please?

(and disable these levels if you don't want to see them in your logs)

On Thu, Feb 2, 2012 at 7:42 PM, Tomas Kuliavas
tokul@users.sourceforge.net wrote:

2012.02.02 19:42 Reindl Harald rašė:

security is THE benefit for ALL users, especially in days where many
are running crap-code like Joomla/Wordpress with all sorts of plugins
throwing millions of warning if you run with E_ALL and E_STRCIT

E_STRICT throws notices on properly written code. It contains coding
recommendations that are not compatible with older PHP and code has to
choose between losing backwards compatibility or suppressing those
notices. In some PHP versions suppressing of E_STRICT will also suppress
fatal errors caused by buggy interpreter.

Latest PHP with deprecation notices in E_ALL also throws lots of shit
which does not apply to version you are running.

--
Tomas

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Reindl Harald — view source — reply

unread

Am 02.02.2012 19:42, schrieb Tomas Kuliavas:

2012.02.02 19:42 Reindl Harald rašė:

security is THE benefit for ALL users, especially in days where many
are running crap-code like Joomla/Wordpress with all sorts of plugins
throwing millions of warning if you run with E_ALL and E_STRCIT

E_STRICT throws notices on properly written code. It contains coding
recommendations that are not compatible with older PHP and code has to
choose between losing backwards compatibility or suppressing those
notices. In some PHP versions suppressing of E_STRICT will also suppress
fatal errors caused by buggy interpreter.

Latest PHP with deprecation notices in E_ALL also throws lots of shit
which does not apply to version you are running.

well, someone may like this

but there is no single reason that E_ALL or E_WARNING throws any line
i be there, since 8 years now running it in prorudction for over 500
domains with self developed code AND a cron-job which will mail me
ANY warning in the errorlog every 30 minutes

so nobdy out there can tell me it is impossible to write clean code

13 years ago by Soenke Ruempler - Jimdo — view source — reply

unread

Hi!it sucks major ass, as

yes, but suhosin-extension and hardening patch exists since many years

the question from a normal user:
why are these things not included in the core?

Because some of these things slow down the code and thus may not be
beneficial to the most users.

So, I respect everyone of you, but please consider:

Most users ==== low traffic webhosting stuff, people will never ever
notive performance penantly within millisesond intervals. They neither
care about security nor about performance.

Minority of users ==== facebook, flickr, etsy -> they know what they do
and they can scale horizontally and optimize PHP by their own (HINT:
HipHop). You, the PHP core team, do not have to care about their website
slowing down. They have people that know the advantages and
disadvantages of PHP.

YOUR responsibility as the provider (READ: provider) of a
programming-language is to provide a secure environment in favor a
micro-optimized performance.

So, sorry guys but this performance argument is simply really BOGUS for
99.99999% of your users. Optimizing bytecodes is cool but securing the
interwebs is just more important.

Please first provide a default secure config and second you might
document the more unsecure setting by saying "you know what you do".

Otherwise you are wasting millions of dollars of money of other people.
People will leave you, PHP will get more and more hilarious.

It doesn't matter if you like Stefan Esser or not. He may not be the the
most sensible or nicest guy in the world but he's probably the best php
security expert. He might be an asshole, jerk or whatever, BUT he shares
his experience and knowledge via CODE (!). He does not (directly) earn
money with it. You can ignore his trolling statements and just use his
code. It will at most touch your honor.

I know it's hard because he personally attacks people and this doesn't
help at all, but deal with him. He really made PHP and the interwebs
more secure for the last decade.

Do not respect him for how (bad) he's communicating things, respect him
for what he coded. We are coders.

Be humble and get shit done. Really.

--

best regards,

Soenke Ruempler // @s0enke
Development

Jimdo GmbH - Pages to the People.
Stresemannstr. 375 | 22761 Hamburg | Germany
Tel: +49 40 82244999 | Fax: +49 40 82244998

Geschäftsführer: F. Detzner | M. Henze | C. Springub
Amtsgericht Hamburg, HRB 101417

mailto: soenke@jimdo.com
Create your own JimdoFree-Page at http://www.jimdo.com!

13 years ago by Pierre Joye — view source — reply

unread

hi,

On Fri, Feb 3, 2012 at 1:48 AM, Soenke Ruempler - Jimdo
soenke@jimdo.com wrote:

YOUR responsibility as the provider (READ: provider) of a
programming-language is to provide a secure environment in favor a
micro-optimized performance.

This is in so many ways wrongly formulated. This is what we do,
always. Today (as in the last years) security is our top concerns.

The only responsibility we have is to deliver the best possible PHP.
And this always has been a matter of compromises.

Please first provide a default secure config and second you might
document the more unsecure setting by saying "you know what you do".

That's the case. If you know areas where we do not that, please let us know.

Do not respect him for how (bad) he's communicating things, respect him
for what he coded. We are coders.

Be humble and get shit done. Really.

For one, I am. I have been asking for years now to propose the missing
features so we can include them if desired. I myself implemented
features that happen to be provided by Suhosin. But to ask us to take
all or nothing is not going to happen as we are not convinced at all
that everything in Suhosin is actually a good thing.

The RFC process now allows everyone to propose such thing, including
you or Stefan (who still refused to do it). Happy proposing! And I
will be the 1st to welcome you.

Now that it is cleared (was already before, but better three times
than none), can we get back to the technical details of this
discussion and see what are actually the technical issues behind this
decision?

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Stefan Esser — view source — reply

unread

Hello Soenke,

I know it's hard because he personally attacks people and this doesn't
help at all, but deal with him. He really made PHP and the interwebs
more secure for the last decade.

Do not respect him for how (bad) he's communicating things, respect him
for what he coded. We are coders.

I am not attacking people personally. Telling someone that he looks very stupid, because he did something stupid is not a personal attack. It is stating the facts.

How does it not look stupid for the "lead" maintainer of PHP in Debian* to write a "We do not need Suhosin, because I believe there will be no future Bugs in PHP" mail the very same day various PHP distributions have to put out updates because of a critical security bug that INFACT is mititgated by PHP.
People don't get that saying we do not need Suhosin because there have been no such critical bugs is like saying: we code perfectly we do not need ASLR, NX, Fortify Source, ...

And it does not only look stupid to write such a mail at that moment it also shows how disconnected the Debian PHP maintainers are from what is happening around PHP.
It also shows that the PHP devs seem to not like the Debian people, because otherwise they would have kept him in the loop. I know for a fact that Ubuntu and Redhat were informed.

So instead of telling me that I am bad with communication they should start critizicing themself.

Regards,
Stefan

*well I heard there is no such thing as a lead maintainer in Debian, but he takes the lead at the moment

13 years ago by Stefan Esser — view source — reply

unread

Hey,

How does it not look stupid for the "lead" maintainer of PHP in Debian* to write a "We do not need Suhosin, because I believe there will be no future Bugs in PHP" mail the very same day various PHP distributions have to put out updates because of a critical security bug that INFACT is mititgated by PHP.
of course that should read: mitigated by Suhosin.

13 years ago by Pierre Joye — view source — reply

unread

hi Stefan,

Hello Soenke,

I know it's hard because he personally attacks people and this doesn't
help at all, but deal with him. He really made PHP and the interwebs
more secure for the last decade.

Do not respect him for how (bad) he's communicating things, respect him
for what he coded. We are coders.

I am not attacking people personally. Telling someone that he looks very stupid, because he did something stupid is not a personal attack. It is stating the facts.

OH! Please! Please! Can we move this discussion at a technical level?

How does it not look stupid for the "lead" maintainer of PHP in Debian* to write a "We do not need Suhosin, because I believe there will be no future Bugs in PHP" mail the very same day various PHP distributions have to put out updates because of a critical security bug that INFACT is mititgated by PHP.
People don't get that saying we do not need Suhosin because there have been no such critical bugs is like saying: we code perfectly we do not need ASLR, NX, Fortify Source, ...

Again, please tell me which part of Suhosin would make sense to have
in the core? With technical explanation or details. Then we can begin
a good discussion and maybe a RFC to get them in.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Stefan Esser — view source — reply

unread

Hello Pierre,

Again, please tell me which part of Suhosin would make sense to have
in the core? With technical explanation or details. Then we can begin
a good discussion and maybe a RFC to get them in.

what part of "all of it and I am not going to try to convince you about this" do you not understand?

I am not interested in pushing Suhosin into PHP mainline. Why in hell would I want that. If Suhosin gets absorbed by PHP.net then I would have to start a new project, because there are tons of mitigations I can think up that will be implemented at some point in time and will never make it into PHP mainline.

With Suhosin existing I am free to implement as many security mitigations I like and do not have to beg the PHP developers to consider adding something.

Regards,
Stefan

13 years ago by Lester Caine — view source — reply

unread

Stefan Esser wrote:

I am not interested in pushing Suhosin into PHP mainline. Why in hell would I want that. If Suhosin gets absorbed by PHP.net then I would have to start a new project, because there are tons of mitigations I can think up that will be implemented at some point in time and will never make it into PHP mainline.

All my production systems have suhosin installed and have done since SUSE
provided it by default. Just like eaccelerator, I am more than happy with these
third party enhancements to PHP. Once again, the drive is to 'push everything
into core' when it makes MUCH more sense to provide a much cleaner and
consistent management system for a modular approach. SOME key features of
suhosin do have a place in PHP, but others would not 'find approval', so
removing suhosin is simply not an option. Cherry picking features that some
contributors find useful is no replacement for well constructed third party
modules, so they too need to work in harmony rather than continually battling to
maintain compatibility. Some 'features' are not commonly required, and providing
them as external modules is always going to be the ideal answer!

There is no 'demand' here for any support of these third party packages by the
php developers, only that they recognise that some changes being made may result
in problems down stream which it may be nicer to accept and address rather than
simply saying "we don't support that" and sticking two fingers up :(

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

what part of "all of it and I am not going to try to convince you
about this" do you not understand?

Well, here's the answer why Suhosin is not part of PHP.

With Suhosin existing I am free to implement as many security
mitigations I like and do not have to beg the PHP developers to
consider adding something.

Some people call "begging" collaboration and consider it a normal way to
develop software with teams bigger than one person. Of course, being
part of the team is completely voluntary. I think it is clear that
Stefan is not interested in doing this. If somebody would want to take
on himself working as part of PHP team on getting some features from
Suhosin to PHP, he's welcome.
One thing I do not understand though is how it is possible to say this
and then complain about the lack of cooperation from PHP developers.
When we explicitly invite you to participate, and you refuse - it's
totally OK, you have no obligations towards us. But then claim that PHP
developers refuse to cooperate? I don't get it.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Pierre Joye — view source — reply

unread

One thing I do not understand though is how it is possible to say this and
then complain about the lack of cooperation from PHP developers. When we
explicitly invite you to participate, and you refuse - it's totally OK, you
have no obligations towards us. But then claim that PHP developers refuse to
cooperate? I don't get it.

And if security features in Suhosin is so critical, I also why its
users rely on one single person for that, the bus factor is quite
high.

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Stefan Esser — view source — reply

unread

Hi Pierre,

And if security features in Suhosin is so critical, I also why its
users rely on one single person for that, the bus factor is quite
high.

everybody is free to join the Suhosin team.

People rely on me because they consider me the person knowing most about PHP security.
And the same people do not trust PHP.net anymore.

Don't forget that the last 2 releases of PHP had to be followed by new versions because both times code was commited AFTER the last RC that introduced a security vulnerability.
People do not trust you anymore. And it is a joke that you are running around telling everyone that all is perfect now with your RFC and new processes.

Reality shows a different picture.

BTW: "rely on a single person" is also funny. At SektionEins we have more than one person looking into Suhosin.

Regards,
Stefan Esser

13 years ago by Stefan Esser — view source — reply

unread

Good morning,

Well, here's the answer why Suhosin is not part of PHP.

With Suhosin existing I am free to implement as many security
mitigations I like and do not have to beg the PHP developers to
consider adding something.

Some people call "begging" collaboration and consider it a normal way to develop software with teams bigger than one person. Of course, being part of the team is completely voluntary. I think it is clear that Stefan is not interested

The Suhosin project was started because I personally considered the state of PHP security not good enough for MY SERVERS.
And while you don't like it the security history of PHP (and the fact how often a bug never even affected Suhosin patched PHP) has proven that I was right.

I want to have the best possible protection on MY SERVERS.

The fact that others can use Suhosin is a gift from me. I could keep the project completely to myself (or let people pay for it). But I did not.
But instead of accepting the gift, people like Pierre run around and tell everybody that people only have more problems due to Suhosin, that he is happy that it gets dropped, bla bla bla.
This is ironic because Pierre's employer is Microsoft (excuse me if that is not correct anymore). Microsoft created "recently" Suhosin for Windows. They call it EMET and they actively support it, not fight it like cancer.

I see NO REASON why I should kill Suhosin and maybe 5 of 100 features/mitigations go into mainline PHP.
If that happens it is not good enough for me. I want all 100 features/mitigations in MY SERVERS.

A suhosin that is merged to PHP mainline will never provide the same security as an external solution.
This is not good enough for me.

Also PHP.net demands that I convince them to take feature A, B and F from Suhosin into PHP. I get ordered to sit down and write RFCs about these features and explain why they need to go inside.
Why should I waste my time like that? I know for sure that whatever will be the outcome of it, it will be a compromise (if at all) that will not be sufficient for my personal taste.
So in the end from my point of view people have to use Suhosin anyway. Why also waste time merging 5 features of 100 if I can do something more useful in the time and give my Suhosin users 20 more new mitigations.

Also history has proven that sooner or later PHP.net gets bitten by some vulnerability in the ass and then they will clone one of the Suhosin features anyway.

Regards,
Stefan Esser

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

A suhosin that is merged to PHP mainline will never provide the same
security as an external solution. This is not good enough for me.

That's your opinion and you completely entitled to it and I have
absolutely no issue about it. As I have no issue with your preferring to
keep Suhosin as a separate project - it's your code, you decide what to
do with it. What I have an issue with is understanding how, after all
public invitations and discussion, you claim that we refuse to cooperate
and "fight you like cancer".

Also PHP.net demands that I convince them to take feature A, B and F
from Suhosin into PHP. I get ordered to sit down and write RFCs about

Nobody demands anything from you. However, for a feature to be included
in PHP it needs to go through certain process. It's not because we hate
you and this process is not personal for you, it's because this is how
projects which have more than one person must work (I'm feeling stupid
spelling out obvious things, but it looks like it's impossible to avoid
it) if they don't want to descend into complete chaos.
If you prefer not to do it - your right, it's your time and I'm sure you
have much better uses for it. But then there's no place to complain that
PHP developers refuse to cooperate and mistreat you.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Stefan Esser — view source — reply

unread

Hello Stas,

That's your opinion and you completely entitled to it and I have absolutely no issue about it. As I have no issue with your preferring to keep Suhosin as a separate project - it's your code, you decide what to do with it. What I have an issue with is understanding how, after all public invitations and discussion, you claim that we refuse to cooperate and "fight you like cancer".
The problem is when people like Pierre run around and tell in public that people have only more problems due to Suhosin, that he is happy that distributions kick it. He also tells everybody that he sees no need in any of the Suhosin features and is VERY VOCAL about it. Nevertheless PHP 5.3.9 introduced a vulnerability because PHP.net cloned one of those "we see no need for any features" features.

Also Pierre runs around every time I mention that Suhosin is not bitten by a bug and accuses me of blatant advertisement or he just downplays the fact that Suhosin users were relatively save from the critical major vulnerability in PHP 5.3.9.

He is actively lobbying against Suhosin and spreading FUD. That is pretty much like fighting it like cancer.

Nobody demands anything from you. However, for a feature to be included in PHP it needs to go through certain process. It's not because we hate you and this process is not personal for you,
Please read the email form Pierre: I see no sense in other features of Suhosin. Write some RFC to convince us to include them.

And BTW you cannot play the: It is Pierre you know him card. The PHP developers are free to step up and say publicly that Pierre's view is not that of the developers. But you choose to not to do so. So you are behind him.

Regards,
Stefan

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

Nevertheless PHP 5.3.9 introduced a vulnerability because PHP.net
cloned one of those "we see no need for any features" features.

Vulnerability was introduced because of the security fix for a specific
problem, that unfortunately was done incorrectly. If this feature were
requested before and it were motivated, the fix would appear earlier. As
you are not interested in doing this and nobody else did this too, it
did not happen. That's all there is to it. It is sad that you seem to
frame this as if there's some conflict between PHP as a project and
yourself, where PHP project members engage in war against you and at the
same time "clone" your ideas. It is very unfortunate way of approaching
it and very unproductive one. Your complaints with Pierre
notwithstanding - and I will not discuss them, you're both grown ups and
can do it without me - I think it would be much more helpful to continue
the cooperation on technical matters. I would want it to be better, but
it takes two to tango, so if it's not to be, so be it. I just want to
make it clear that the invitation is there. And of course we will
"clone" any security feature that we think will make overall working
with PHP better - if and when we see this is the case.

And BTW you cannot play the: It is Pierre you know him card. The PHP
developers are free to step up and say publicly that Pierre's view is
not that of the developers. But you choose to not to do so. So you
are behind him.

If it was not clear that Pierre's views are Pierre's views, and my views
are my views, and anybody else's views in PHP project is his views and
we don't share a hive mind but instead each has his own mind and thus
has independent views and capable of discussing them and hashing out
inevitable differences in views and disagreements and we regularly and
publicly do it - here's you declaration, this is exactly the case. We're
a diverse group of individuals having a lot of differences but a common
goal of supporting the PHP project.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Pierre Joye — view source — reply

unread

hi Stefan,

But instead of accepting the gift, people like Pierre run around and tell everybody that people only have more problems due to Suhosin, that he is happy that it gets dropped, bla bla bla.

Yes, it causes more issues that it solves in the long run. That's my
experiences and the same has been told by other people. There is no
personal reason behind it, but pure technical experiences.

This is ironic because Pierre's employer is Microsoft (excuse me if that is not correct anymore).

Again you are totally wrong. I work with them not for.

And can you please once in this thread (or at all) stop your kiddish
personal attack and finally bring technical points to this discussion?
Can you do it?

Microsoft created "recently" Suhosin for Windows. They call it EMET and they actively support it, not fight it like cancer.

It is a very pretentious to consider that EMET has been created from
or because of Suhosin. Also some Suhosin features are per se enabled
on Windows through VC options (whehter they act the same way or not is
disputable but you know it).

I see NO REASON why I should kill Suhosin and maybe 5 of 100 features/mitigations go into mainline PHP.
If that happens it is not good enough for me. I want all 100 features/mitigations in MY SERVERS.

Nobody ever asked you to kill it. never. But we did kindly and
friendly ask you to participate instead of doing your little crusades
like these days.

A suhosin that is merged to PHP mainline will never provide the same security as an external solution.
This is not good enough for me.

That's your opinion, I'm convinced of the opposite. The issue here is
that you lived in the past, based on your experiences with php core
years ago, php3/4 and partially 5/5.2. It is really time for you to
wake up.

Also PHP.net demands that I convince them to take feature A, B and F from Suhosin into PHP.

It is a standard procedure that applies to any new feature. Many
projects do that as well. There is no exception, even for you.

I get ordered to sit down and write RFCs about these features and explain why they need to go inside.

Please double read my replies, I do not see any order but kind suggestions.

And yes, I do lobby against Suhosin because I consider it causes more
harms to the whole thing that what it solves. That's my rights and I
do not engage php.net in my statement but only my personal opinions.
And I will continue to lobby, actually not against Suhosin, but to get
what PHP needs in PHP and not in some random external patches.

I also try to convince you to finally get around your personal issues
with us and join our efforts. I do that every time we meet live at
conferences or other events. It is also somehow amusing that you are
much more polite and nice in a live discussion than through emails,
let try to solve that next time we meet :-)

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Stefan Esser — view source — reply

unread

Hello Pierre,

This is ironic because Pierre's employer is Microsoft (excuse me if that is not correct anymore).

Again you are totally wrong. I work with them not for.

And can you please once in this thread (or at all) stop your kiddish
personal attack and finally bring technical points to this discussion?
Can you do it?

Grow up Pierre. Telling people that you work for Microsoft while you only work with them is not a personal attack.
The technical points are all over my emails. You just choose to ignore them and highlight every second sentence of mine as personal attack.

Microsoft created "recently" Suhosin for Windows. They call it EMET and they actively support it, not fight it like cancer.

It is a very pretentious to consider that EMET has been created from
or because of Suhosin. Also some Suhosin features are per se enabled
on Windows through VC options (whehter they act the same way or not is
disputable but you know it).
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.

Nobody ever asked you to kill it. never. But we did kindly and
friendly ask you to participate instead of doing your little crusades
like these days.
No, you ordered me to sit down and write RFC so that I can convince YOU.

A suhosin that is merged to PHP mainline will never provide the same security as an external solution.
This is not good enough for me.

That's your opinion, I'm convinced of the opposite. The issue here is
that you lived in the past, based on your experiences with php core
years ago, php3/4 and partially 5/5.2. It is really time for you to
wake up.
Pierre it is time for you to come out of the delusional state. You repeatedly claim that everything is now superb.
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.

Also PHP.net demands that I convince them to take feature A, B and F from Suhosin into PHP.

It is a standard procedure that applies to any new feature. Many
projects do that as well. There is no exception, even for you.
No it is not a standard procedure that you order someone that does not see a need to merge features into PHP to sit down and write RFC to convince you nevertheless.

And yes, I do lobby against Suhosin because I consider it causes more
harms to the whole thing that what it solves. That's my rights and I
do not engage php.net in my statement but only my personal opinions.
And I will continue to lobby, actually not against Suhosin, but to get
what PHP needs in PHP and not in some random external patches.

Enough said.

I also try to convince you to finally get around your personal issues
with us and join our efforts. I do that every time we meet live at
conferences or other events. It is also somehow amusing that you are
much more polite and nice in a live discussion than through emails,
let try to solve that next time we meet :-)

You claim I have personal issues, while I repeatedly tell you the technical reasons why I see it different then you.

Regards,
Stefan

13 years ago by Pierre Joye — view source — reply

unread

Grow up Pierre.

here we go again... failed. next time....

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.

I was talking about the compilation security options which are similar
(in some extends) to what Suhosin does (for some features).

Pierre it is time for you to come out of the delusional state. You repeatedly claim that everything is now superb.

No, I said it is different and better than what you have experienced.
And anyone active today in php.net can tell you the same.

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?

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.

You claim I have personal issues, while I repeatedly tell you the technical reasons why I see it different then you.

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.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Stefan Esser — view source — reply

unread

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.

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.

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

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

This is bad. And there is no point arguing this fact.

Yes, this was bad. Agreed. It was a mistake. Mistakes happen. We fixed
it and hopefully learned from it.

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.

Because there's a difference between principles and applying them in a
particular manner in particular patch to particular software. The
responsibility of core PHP developers it to evaluate the specific
solutions and patches and decide if they are good or not. Regardless of
how well or badly it was done in specific cases in the past, this is
what should be done. If the author of the patch doesn't want to do this

well, ok, so he would have his patch and we probably won't, unless we
find other ways to do it - maybe even the worst way possible, by having
security problem illuminate the need - but I see no way around it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Stefan Esser — view source — reply

unread

Hi,

This is bad. And there is no point arguing this fact.

Yes, this was bad. Agreed. It was a mistake. Mistakes happen. We fixed
it and hopefully learned from it.

Yes mistakes do happen to everyone and we all hope to learn from them.
And some of us like to buy insurances so that there is protection in case anything goes wrong.
And because we know that everyone makes mistakes we add additional layers of protection.
In case of PHP this is Suhosin. In case of Apache this is mod_security. In case of Linux it is better Grsecurity (and not the other stuff).
And in case of webservers in general people buy web application firewalls.

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.

Because there's a difference between principles and applying them in a particular manner in particular patch to particular software. The responsibility of core PHP developers it to evaluate the specific solutions and patches and decide if they are good or not. Regardless of how well or badly it was done in specific cases in the past, this is what should be done. If the author of the patch doesn't want to do this - well, ok, so he would have his patch and we probably won't, unless we find other ways to do it - maybe even the worst way possible, by having security problem illuminate the need - but I see no way around it.

The patches are available for everyone. You can download them at http://suhosin.org - also everyone can use them for free. Everyone can just take them and merge them into PHP.
But it will not be me. As I previously stated I can live with a few percent less performance or more memory usage due to memory canaries. (The later can actually be largely improved and I have plans to do it somewhen in the next months). However I know that memory canaries will never go into PHP mainline.

And knowing that tells me that I have to keep Suhosin anyway as a project. And therefore people should use it.
And all those that maybe cannot live with this impact can already use Suhosin today and just disable the memory canaries via environment variables.

Regards,
Stefan

13 years ago by Pierre Joye — view source — reply

unread

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.

Why do you need a RFC to propose something to the W3C, or python? Even
if it is widely adopted already. No need to answer, that's rather
obvious.

Cheers.

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Stefan Esser — view source — reply

unread

Pierre,

Why do you need a RFC to propose something to the W3C, or python? Even
if it is widely adopted already. No need to answer, that's rather
obvious.

you still fail to realize that I don't want to propose (anything) to you.
If you love writing RFCs then write some.

I am perfectly satisfied with people having the choice to just use my stuff or not.
I do not need to write RFCs to make PHP more secure in the future. Instead people have TODAY the choice to just install Suhosin and get that extra bit of security.

I am merely informing people that from my point of view (and most people in the web security community agree) using PHP without Suhosin is a bad choice.
And If you disagree that is your problem. By lobbying against Suhosin you are not hurting me or Suhosin, you are hurting the internet.

-stefan

13 years ago by Pierre Joye — view source — reply

unread

Pierre,

Why do you need a RFC to propose something to the W3C, or python? Even
if it is widely adopted already. No need to answer, that's rather
obvious.

you still fail to realize that I don't want to propose (anything) to you.
If you love writing RFCs then write some.

I do understand that and seriously, it is not really an issue.

However you keep saying that we should not do that or that RFCs are
not needed for these additions (if that ever comes) because it is
widely used. And that is totally wrong. Now I think we are done :)

Enjoy your weekend!

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Stefan Esser — view source — reply

unread

Pierre,

I think we all know that 90% of your emails consist of twisting other people's words in the hope to make them look bad
and redirect from the technical content.

Every time in this threat you replied to me, you were not adressing the technical issue but taking some sentences and
twisting the words and play "offended" e.g. for calling you an Microsoft employee, while you yourself claim that on LinkedIn.

You repeatedly claimed that I said A, B or C, while that infact is not the case.

This trick might work on the average mind in the PHP community, but not on me.

However you keep saying that we should not do that or that RFCs are
not needed for these additions (if that ever comes) because it is
widely used. And that is totally wrong. Now I think we are done :)

I never said that your RFCs are a bad idea. I said that I will not write your RFCs. And I see no need in an RFC about something that will not happen anyway.

And that said I consider this discussion done from my side and I will not reply to any other mail from you.

-stefan

13 years ago by Michael Morris — view source — reply

unread

Having watched this discussion unfold, I for one intend to discontinue
using Sushonin. I advise others to do the same. The character displayed by
Stefan throughout this thread speaks for itself as to why.

Pierre,

I think we all know that 90% of your emails consist of twisting other
people's words in the hope to make them look bad
and redirect from the technical content.

Every time in this threat you replied to me, you were not adressing the
technical issue but taking some sentences and
twisting the words and play "offended" e.g. for calling you an Microsoft
employee, while you yourself claim that on LinkedIn.

You repeatedly claimed that I said A, B or C, while that infact is not the
case.

This trick might work on the average mind in the PHP community, but not on
me.

However you keep saying that we should not do that or that RFCs are
not needed for these additions (if that ever comes) because it is
widely used. And that is totally wrong. Now I think we are done :)

I never said that your RFCs are a bad idea. I said that I will not write
your RFCs. And I see no need in an RFC about something that will not happen
anyway.

And that said I consider this discussion done from my side and I will not
reply to any other mail from you.

-stefan

13 years ago by Reindl Harald — view source — reply

unread

Am 06.02.2012 16:00, schrieb Michael Morris:

Having watched this discussion unfold, I for one intend to discontinue
using Sushonin. I advise others to do the same. The character displayed by
Stefan throughout this thread speaks for itself as to why.

if your make technical decisions especially security ones by
"The character displayed by Stefan" you are maybe doing the
wrong job!

13 years ago by Michael Morris — view source — reply

unread

I don't think so. My experience with the attitude he has shown is, when
mistakes get made by such a person, they are hidden away rather than
honestly reported. To paraphrase a line from Harry Potter - brilliant
people don't make many mistakes, but the ones they make tend to be large
and very damaging.

Security is trust. Given what I have seen I do not trust Stefan to report
any vulnerabilities created in PHP by Sushonin in a timely manner. I do not
believe he has the humility necessary to own up to a mistake. Since he is
that project's only caretaker, I cannot trust the code. If I do not trust
it, I don't run it.

On Mon, Feb 6, 2012 at 10:15 AM, Reindl Harald h.reindl@thelounge.netwrote:

if your make technical decisions especially security ones by
"The character displayed by Stefan" you are maybe doing the
wrong job!

13 years ago by Reindl Harald — view source — reply

unread

first: do not top-post if you get a reply below

second:
in the context of suhosin "when mistakes get made by such a person,
they are hidden away rather than honestly reported" is bullshit
at it's best

look at the disclosure below
look at the author
look at the way it was made

if only 10% of developers would work like Stefan most software
out there would be much better as it is and was all the last years
and if someone has this attitude and knowledge is see no single
problem and understand fully that he is frustrated

Author: Stefan Esser [stefan.esser[at]sektioneins.de]

Disclosure Timeline:

January 2012 - Vulnerability was found during an internal audit
January 2012 - Vulnerability was fixed in the source code
January 2012 - Public Disclosure

Am 06.02.2012 16:23, schrieb Michael Morris:

I don't think so. My experience with the attitude he has shown is, when
mistakes get made by such a person, they are hidden away rather than
honestly reported. To paraphrase a line from Harry Potter - brilliant
people don't make many mistakes, but the ones they make tend to be large
and very damaging.

Security is trust. Given what I have seen I do not trust Stefan to report
any vulnerabilities created in PHP by Sushonin in a timely manner. I do not
believe he has the humility necessary to own up to a mistake. Since he is
that project's only caretaker, I cannot trust the code. If I do not trust
it, I don't run it.

On Mon, Feb 6, 2012 at 10:15 AM, Reindl Harald h.reindl@thelounge.netwrote:

if your make technical decisions especially security ones by
"The character displayed by Stefan" you are maybe doing the
wrong job!

-------- Original-Nachricht --------
Betreff: Advisory 01/2012: Suhosin PHP Extension Transparent Cookie Encryption Stack Buffer Overflow
Datum: Thu, 19 Jan 2012 17:18:23 +0100
Von: Stefan Esser stefan.esser@sektioneins.de
An: Full-Disclosure full-disclosure@lists.grok.org.uk, Bugtraq bugtraq@securityfocus.com

                     SektionEins GmbH
                    www.sektioneins.de

                 -= Security  Advisory =-

 Advisory: Suhosin PHP Extension Transparent Cookie Encryption Stack

Buffer Overflow
Release Date: 2012/01/19
Last Modified: 2012/01/19
Author: Stefan Esser [stefan.esser[at]sektioneins.de]

Application: Suhosin Extension <= 0.9.32.1
Severity: A possible stack buffer overflow in Suhosin extension's
transparent cookie encryption that can only be triggered
in an uncommon and weakened Suhosin configuration can lead
to arbitrary remote code execution, if the FORTIFY_SOURCE
compile option was not used when Suhosin was compiled.
Risk: Medium
Vendor Status: Suhosin Extension 0.9.33 was released which fixes this
vulnerability
Reference: http://www.suhosin.org/
https://github.com/stefanesser/suhosin

Overview:

Quote from http://www.suhosin.org
"Suhosin is an advanced protection system for PHP installations.
It was designed to protect servers and users from known and
unknown flaws in PHP applications and the PHP core. Suhosin comes
in two independent parts, that can be used separately or in
combination. The first part is a small patch against the PHP
core, that implements a few low-level protections against
buffer overflows or format string vulnerabilities and the second
part is a powerful PHP extension that implements all the other
protections.."

During an internal audit of the Suhosin PHP extension, which is
often confused with the Suhosin PHP Patch, although they are not
the same, a possible stack based buffer overflow inside the
transparent cookie encryption feature was discovered.

If successfully exploited this vulnerability can lead to arbitrary
remote code execution. However further investigation into the
vulnerability revealed that it can only be triggered if the admin
has not only activated transparent cookie encryption, but also
explicitly disabled several other security features of Suhosin.
In addition to that remote exploitation requires a PHP application
that puts unfiltered user input into a call to the header()
function that sends a Set-Cookie header.

Furthermore most modern unix systems compile the Suhosin extension
with the FORTIFY_SOURCE flag, which will detect the possible buffer
overflow and abort execution before something bad can happen.

Details:

The transparent cookie encryption of Suhosin is disabled by default
because it stops applications using JavaScript to access cookies,
which would break these applications. In order to activate it an
admin has to enable this feature in the configuration file:

suhosin.cookie.encrypt = On

Once activated all incoming cookies will be decrypted and all
outgoing Set-Cookie HTTP headers will be rewritten to only contain
encrypted data. When this happens the following code of Suhosin
extension will be triggered.

char *suhosin_encrypt_single_cookie(char *name, int name_len, char

*value, int value_len, char *key TSRMLS_DC)
{
char buffer[4096];
char buffer2[4096];
char *buf = buffer, *buf2 = buffer2, *d, *d_url;
int l;

    if (name_len > sizeof(buffer)-2) {
        buf = estrndup(name, name_len);
    } else {
        memcpy(buf, name, name_len);
        buf[name_len] = 0;
    }

    ...

    if (strlen(value) <= sizeof(buffer2)-2) {
        memcpy(buf2, value, value_len);
        buf2[value_len] = 0;
    } else {
        buf2 = estrndup(value, value_len);
    }

The problem with this code is that the second call to mempcy()
uses strlen() to check if there is enough buffer space but
uses the variable value_len to determine the amount of bytes
to copy. The problem is that there could be a NUL byte inside
the value of the cookie, which will result in a stack based
buffer overflow. While the same code can also be found inside
the suhosin_decrypt_single_cookie() function the problem cannot
be exploited, because in that case there cannot be a NUL byte.

To understand the limited impact of this vulnerability it is
important to know that NUL bytes are not allowed inside HTTP
headers in a default Suhosin installation. In order to be
vulnerable it is therefore required that the admin explicitly
weakened security by disabling the HTTP response splitting
protection of Suhosin by using the following configuration:

suhosin.multiheader=On

The next thing to know is that PHP applications normally use
the functions setcookie() and setrawcookie() to set cookies.
Both functions are however not affected by the problem
because both functions will eliminate a possible NUL byte
when constructing the Set-Cookie header. Therefore the only
way to trigger this vulnerability is to call the header() function
directly with a "Set-Cookie" header and put unfiltered user
input into the cookie value. This is very uncommon in normal
PHP applications.

In addition to that the default configuration of Suhosin will not
allow NUL bytes in user input. Therefore in order to trigger the
vulnerability remotely the user input must have been double
decoded or the admin must have weakened the installation once
again by disabling the protection against NUL bytes. This can be
done by changing the configuration to.

suhosin.request.disallow_nul=Off
suhosin.get.disallow_nul=Off
suhosin.post.disallow_nul=Off
suhosin.cookie.disallow_nul=Off

Finally even if the vulnerability is triggerable from remote it
depends on the compilation of the Suhosin extension if the bug
can be abused. Most modern unix systems will compile the Suhosin
extension with the FORTIFY_SOURCE compile option, which will
detect the buffer overflow before it actually happens and abort
execution.

If either suhosin.multiheader or suhosin.cookie.encrypt are set
to "off" in your configuration than you are safe from remote
attacks. In addition to that the default configuration of
suhosin.perdir disallows to set these variables from .htaccess
which also provides some protection against local attackers.

Proof of Concept:

Locally the problem can be reproduced by the following PHP code:

<?php header("Set-Cookie: x=xxx".chr(0).str_repeat("A",10000));

If this piece of code does not affect your PHP process at all then
your current configuration is safe. Otherwise it depends if the
Suhosin extension was compiles with the FORTIFY_SOURCE option.

Disclosure Timeline:

January 2012 - Vulnerability was found during an internal audit
January 2012 - Vulnerability was fixed in the source code
January 2012 - Public Disclosure

Recommendation:

It is recommended to upgrade to the latest version of Suhosin
extension, which can be downloaded at:

http://www.suhosin.org

The latest development version of the Suhosin extension can always
be found at:

https://github.com/stefanesser/suhosin

CVE Information:

The Common Vulnerabilities and Exposures project (cve.mitre.org) has
not assigned a name to this vulnerability.

13 years ago by Gustavo Lopes — view source — reply

unread

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.

Curious choice of words, because the "drama" was entirely fabricated by
you. What could have been an e-mail pointing a fairly trivial (even if
somewhat negligent) bug became an absurd verbiage complete with an
imagined narrative (!), paternalist tone, assumptions about me and the
rest of the developers, futurology and inductive fallacies.

I'm happy that you commented on the issue, not only because of the bug
you pointed out but also because of other problems (like CRLF + (SP or
HT) being disallowed). But I could do without the dramatization, which
just shows (see also the other thread) how pointless it is to engage
with you in anything but strictly technical issues, which I'll refrain
from doing from now on.

--
Gustavo Lopes

13 years ago by marius adrian popa — view source — reply

unread

Grow up Pierre.

here we go again... failed. next time....

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.

I was talking about the compilation security options which are similar
(in some extends) to what Suhosin does (for some features).

Pierre it is time for you to come out of the delusional state. You repeatedly claim that everything is now superb.

No, I said it is different and better than what you have experienced.
And anyone active today in php.net can tell you the same.

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?

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.

You claim I have personal issues, while I repeatedly tell you the technical reasons why I see it different then you.

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 only say a few words and then i will be silent
I tend to agree with Linus on this one "Security people are insane"
http://kerneltrap.org/Linux/Pluggable_Security
If there is something that needs to be done so php core will be more
secure , make it in the core
Not words : write RFC(docs),patches with sane techincal disscussions
or a pluggable architecture with extensions and rules, something like
is done with LSM http://en.wikipedia.org/wiki/Linux_Security_Modules
or mod_security in apache

I vote with the Debian point of view , less patches means faster
releases for php also it means more security
and they are using the vanilla core (less suoshin related bugs to support)

The goal is : 0 patches and use upstream as much as possible

13 years ago by Stefan Esser — view source — reply

unread

Hello,

I only say a few words and then i will be silent
I tend to agree with Linus on this one "Security people are insane"

Yes and the security community thinks that Linus is insane for his view on security topics.

Not words : write RFC(docs),patches with sane techincal disscussions
or a pluggable architecture with extensions and rules, something like
is done with LSM http://en.wikipedia.org/wiki/Linux_Security_Modules
or mod_security in apache
It is funny that you come to this thread not knowing what you are talking about and say we should do something like mod_security for Apache.
You obviously have no idea that the majority of Suhosin features is already inside an extension to PHP.
The only stuff not inside that extension are features that need to be in the core and therefore cannot be in an extension.
And these mitigations inside the core are stuff like memory manager canaries that are considered too much a performance impact by PHP.net.
Therefore these patches have to be in a separate patch. Therefore all the features are in the patch.

Regards,
Stefan

13 years ago by David Ramalho — view source — reply

unread

Guys

sorry to barge in out of the blue, I recently signed up to the internals
list after many years as a PHP user (like many many people of course :) )
and after the recent non-too happy releases. I'm looking ever forward to
the next major PHP release and since I discovered the RFC's list I even
know exactly what I can wait for - or be sad to see dropped . I'm mostly a
feature oriented guy, but I recognize the obvious need too handle the many
vectors that create security problems, and Suhosin has been part of that
fight.

Now, again, coming out of the blue like this means I miss all the finer
points, the many contexts that lead intelligent people (in whatever group
context) to extreme positions, like we're seeing here, I've seen it before,
and I know intelligence and the general will to do good has nothing to do
with it. .

Anyway, keeping it brief, let me give you a user's perspective here about
security and what it means. Technical aspects aside, having an external
component mitigate a language (runtime) vulnerability is not scary for the
external component, it's scary for the flaw actually being there in the
core. Are there good reasons for this? Is it a architectural choice
that inevitability leads to said vulnerability ? I'm guessing it isn't,
because for the most part I don't think Suhosin changes any of the PHP
feature set , so one would say that each of the problems Suhosin fixes
could be fixed right at the source of it all. Now, going through RFC's to
solve problems (not introduce new features) does seem to bring
in bureaucratic work where there isn't a need for one, but I'm also
guessing we all know that and that RFC's aren't used outside the feature
set context.

I also see, despite all this, a place for an external component, almost as
I see a RC version, something like a firstline, more agile way to test code
and solutions, but in the long run, I think everyone here would agree,
something that Suhosin (or others) does better than PHP Core (baring all
the finer contexts that I'm missing, like someone trying to actually make
money out of their work by having a paid product instead of offering it to
the community) would probably be ported into PHP (and out of Suhosin) in
the next development iteration.

Now, guys, as a user here, really, no finger pointing, no nothing, I don't
care much for ego's , not when it means things go slower instead of faster,
AS A USER, I would really like for sense to come in somewhere soon, and to
see PHP moving forward, faster and better :) , and I'm sure the right
people are gathered here to (keep) doing it :)

David Ramalho

ps: no paternalism meant, first email ever here, a very hot topic, put it
in perspective please :) - thanks for reading

Grow up Pierre.

here we go again... failed. next time....

13 years ago by John Crenshaw — view source — reply

unread

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:

What are the pros vs. cons of enabling the Suhosin patch by default?
Why did the Debian team opt to disable it?
Are there better solutions that should be considered and recommended?

John Crenshaw
Priacta, Inc.

13 years ago by Kiall Mac Innes — view source — reply

unread

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 johncrenshaw@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:

What are the pros vs. cons of enabling the Suhosin patch by default?

Why did the Debian team opt to disable it?

Are there better solutions that should be considered and recommended?

John Crenshaw
Priacta, Inc.

13 years ago by Clint Byrum — view source — reply

unread

Excerpts from Kiall Mac Innes's message of Sat Feb 04 09:34:44 -0800 2012:

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.

There are plenty of reasons to use a 3rd party patch. Operating systems
are about supporting an well integrated system. If parts of that system
are breaking integration or eating peoples data, the os integrator
(Debian, RedHat, CentOS, Ubuntu, or even MS in some cases) must act to
support its users.

Staying as close as possible to upstream is absolutely critical for
efficient operation of an Open Source operating system project like Debian
and Ubuntu. However, above efficiency is security. If Suhosin mitigates
security vulnerabilities, lowering the urgency with which fixes must be
rushed out to users, then carrying it as a patch is, IMO, worth it.

I have to sympathize with Ondrej, as I know how much effort he puts into
maintaining the PHP packages in Debian. Its pretty demoralizing pushing
a bug report upstream when you know its likely to get a response of
"please try without Suhosin".

I think a more interesting discussion than the current one of "who
plays nice with whom" and "why I don't like your processes", is whether
anyone other than Stefan would be willing to champion RFCs for all of
the Suhosin patch to enter PHP's core, and be turned on by default.

We've talked briefly in the Ubuntu project about this latest development,
as we generally try to stay as close to Debian's packages as possible.
Members of our security team have expressed reservations about
following Ondrej's lead here. These are the people who have to work
to get vulnerabilities patched in a timely manner across all supported
releases of Ubuntu long after upstream has dropped support (currently
that includes php 5.2.4 - 5.3.6).

So, I think I could probably put myself in as somebody that would support
an effort to bring Suhosin's mitigations into PHP core. I don't know
that the greater Ubuntu roject could devote many man-hours to it, but
perhaps I could write the RFC's and offer resources for testing. Since
the patches are already written, it shouldn't be much code work, right?

I think this would be something to discuss at the next Ubuntu Developer
Summit. I don't believe we'll be disabling Suhosin in the precise release,
scheduled to release as 12.04 in April. However, eliminating deltas
from Debian and the greater community are always a topic that deserves
discussion. I'd invite the PHP community to come and discuss this with
us at this free event in Oakland, CA, USA, May 7 - 11.

http://uds.ubuntu.com/

You can even request travel sponsorship here:

http://summit.ubuntu.com/uds-q/sponsorship

(let me know privately if you apply, and I can ask the organizers to give
your sponsorship request a closer look)

13 years ago by Pierre Joye — view source — reply

unread

hi,

So, I think I could probably put myself in as somebody that would support
an effort to bring Suhosin's mitigations into PHP core. I don't know
that the greater Ubuntu roject could devote many man-hours to it, but
perhaps I could write the RFC's and offer resources for testing. Since
the patches are already written, it shouldn't be much code work, right?

Well, the main work is not to decide to apply a big patch but to
decide what actually makes sense.

That's why I would rather go feature by feature instead, step by step
and carefully instead of the whole or nothing approach.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by jason.gerfen@gmail.com — view source — reply

unread

+1

Not certain about a better solution but there are other methods of encrypting and decrypting session data. In a recent project I have been tasked with implementing a pdo stored procedure using mysql's aes functionality works well with or without the patch. In a lot of ways I think that is the benefit of any programming language. The tools exist, implement them right?

Jas

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:

What are the pros vs. cons of enabling the Suhosin patch by default?

Why did the Debian team opt to disable it?

Are there better solutions that should be considered and recommended?

John Crenshaw
Priacta, Inc.

13 years ago by Pierre Joye — view source — reply

unread

hi Stefan,

And it does not only look stupid to write such a mail at that moment it also shows how disconnected the Debian PHP maintainers are from what is happening around PHP.
It also shows that the PHP devs seem to not like the Debian people, because otherwise they would have kept him in the loop. I know for a fact that Ubuntu and Redhat were informed.

Please state the facts. I did add Debian and Ubuntu to the discussions
on security@php.net. For all the issues you have reported yesterday
(and I do the same for other). I do not know if Ondrej is on the
security debian list, but that's up to them to deal with that.

Yes, as far as I know no more active members are part of the list, but
they are part of the security people on bugs.php.net. Reporting flaws
via bugs.php.net would be actually much better these days as more
people can read it (see the repo for their accounts) and it is
actually archived. And thisis also one of new good things we have
changed recently.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Stefan Esser — view source — reply

unread

Hello Pierre,

Please state the facts. I did add Debian and Ubuntu to the discussions
on security@php.net. For all the issues you have reported yesterday
(and I do the same for other). I do not know if Ondrej is on the
security debian list, but that's up to them to deal with that.

Actually you have not. All mails that went to me were only forwarded to redhat security and ubuntu security.
If you sent any mail to debian than this mail was not CCed to me.

And even if you have done so than the big fuckup is on the side of Debian for not informing their maintainers.

Yes, as far as I know no more active members are part of the list, but
they are part of the security people on bugs.php.net. Reporting flaws
via bugs.php.net would be actually much better these days as more
people can read it (see the repo for their accounts) and it is
actually archived. And thisis also one of new good things we have
changed recently.

Pierre security@php.net was founded by me many years ago, because THIS is the worldwide accepted standard for reporting security problems.
It doesn't matter if your prefered way is bugs.php.net or whatever - standards are there for a reason.

Regards,
Stefan

13 years ago by Stefan Esser — view source — reply

unread

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

13 years ago by Pierre Joye — view source — reply

unread

hi Stefan,

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

13 years ago by jpauli — view source — reply

unread

hi Stefan,

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

--

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

13 years ago by Stefan Esser — view source — reply

unread

Hello Pierre,

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.

Sorry it makes no difference if a feature was introduced into PHP by taking code from Suhosin or from someone else. Fact is the feature existed before in Suhosin.

GLOBALS overwrite protection
max_file_uploads
max_input_vars
crypt() blowfish
max_input_nesting_level
Superglobals overwrite protection in explode()/import_request_vars()
safe unlink in Zend memory manager
http response splitting protection against \n
http response splitting protection against \r <--- broken attempt to support this in PHP 5.4
and most probably many more that I do not know from the top of my head (this are already 9 features and Suhosin/HPHP exists since 2004 = 8 years).

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

Suhosin/HPHP existed 3 years before I left the security team. So the creation of it had nothing todo with me leaving the team.

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.

The fact is the PHP developers NEVER saw other features they needed to implement and then some external people disclosed some PHP bug and as a result one of the Suhosin features were cloned.

The thing is: I see no problem with the status quo - Suhosin exists and people can use it - it is like people can choose if they want ASLR, NX, Fortify Source on their system.
I do not have the time or wish to convince the PHP developers to add some features that most probably after some time will be copied/clones/reimplemented anyway.
The only problem I see is that some PHP developers negate the fact that Suhosin increases security of PHP (which was proven again and again for 8 years, why else clone features) and recommend people to stay away from it: This is malicious.

And yes I like the Suhosin codebase separate, because if there is a bug I can smack the responsible person (myself) over the head bigtime.
If Suhosin merges with PHP a lot of patches will go into the code and the work to keep track with every commit that touches some Suhosin feature will explode.

Just look at security patches like this:

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997

Yes it is one of the features that is in Suhosin for a long time -> anyway that security fix is completely broken and noone cares about it.

Regards,
Stefan Esser

13 years ago by Pierre Joye — view source — reply

unread

Hello Pierre,

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.

Sorry it makes no difference if a feature was introduced into PHP by taking code from Suhosin or from someone else. Fact is the feature existed before in Suhosin.

I corrected your statement, in fact it makes no difference except that
giving back to Caesar...

The thing is: I see no problem with the status quo - Suhosin exists and people can use it - it is like people can choose if they want ASLR, NX, Fortify Source on their system.

I do see a problem and this problem is the reason why I do not think
Suhosin is the right way. To me it creates more issues than it solves.
I cannot count the amount of people I have met (or myself) having
issues using Suhosin while not having them with a vanilla PHP.

I do not have the time or wish to convince the PHP developers to add some features that most probably after some time will be copied/clones/reimplemented anyway.

But you have time to convince them and the distros to use the patch,
there is something wrong here :)

The only problem I see is that some PHP developers negate the fact that Suhosin increases security of PHP (which was proven again and again for 8 years, why else clone features) and recommend people to stay away from it: This is malicious.

You miss the point. And please, make yourself a favour, don't consider
all PHP developers as being one single entity, it is not. The
discussions you could have in the past and what other thinks today are
two different things. In other words, move forward, stop to keep
looking at the past.

And yes I like the Suhosin codebase separate, because if there is a bug I can smack the responsible person (myself) over the head bigtime.

It is indeed easier for you to work with you alone. Now if I put that
from our users base perspective, this argument is totally invalid.

If Suhosin merges with PHP a lot of patches will go into the code and the work to keep track with every commit that touches some Suhosin feature will explode.

Just look at security patches like this:

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997

Yes it is one of the features that is in Suhosin for a long time -> anyway that security fix is completely broken and noone cares about it.

This is exactly where you should help php directly instead of doing
what you do now to defend your patch. In the long run (or maybe even
mid term), the Suhosin patch will disappear.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Stefan Esser — view source — reply

unread

Hello Pierre,

This is exactly where you should help php directly instead of doing
what you do now to defend your patch. In the long run (or maybe even
mid term), the Suhosin patch will disappear.

I seriously doubt that. The PHP developers will never ever merge all features into the PHP core. And therefore Suhosin will continue to add additonal value.
Especially since the next Suhosin-Patch for PHP 5.4.0 will already have new and more mitigations.

Regards,
Stefan

13 years ago by Pierre Joye — view source — reply

unread

hi Stefan,

You do not want that to happen, that's different than we, as a
project, not willing to see what could be done and help you or anyone
to get that done. The RFC process also makes that possible in a very
easy and open way.

Hello Pierre,

This is exactly where you should help php directly instead of doing
what you do now to defend your patch. In the long run (or maybe even
mid term), the Suhosin patch will disappear.

I seriously doubt that. The PHP developers will never ever merge all features into the PHP core. And therefore Suhosin will continue to add additonal value.
Especially since the next Suhosin-Patch for PHP 5.4.0 will already have new and more mitigations.

Regards,
Stefan

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Derick Rethans — view source — reply

unread

Sorry it makes no difference if a feature was introduced into PHP by
taking code from Suhosin or from someone else. Fact is the feature
existed before in Suhosin.

GLOBALS overwrite protection

max_file_uploads

max_input_vars

crypt() blowfish

max_input_nesting_level

Superglobals overwrite protection in explode()/import_request_vars()

safe unlink in Zend memory manager

http response splitting protection against \n

http response splitting protection against \r <--- broken attempt to support this in PHP 5.4

What is broken, and where is a possible patch?

and most probably many more that I do not know from the top of my
head (this are already 9 features and Suhosin/HPHP exists since 2004 =
8 years).

Lots of stuff in PHP was also "stolen" from Xdebug, but I am not whining
about that as the goal is (and has always been) to make PHP better.

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997

Yes it is one of the features that is in Suhosin for a long time ->
anyway that security fix is completely broken and noone cares about
it.

I'm sure we'd be more than happy to hear why it's broken and hear about
possible suggested fixes.

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

13 years ago by Stefan Esser — view source — reply

unread

Hello Derick,

and most probably many more that I do not know from the top of my
head (this are already 9 features and Suhosin/HPHP exists since 2004 =
8 years).

Lots of stuff in PHP was also "stolen" from Xdebug, but I am not whining
about that as the goal is (and has always been) to make PHP better.

I am not whining of something being stolen I trying to demonstrate that a lot of the features noone ever saw a need for in PHP have been cloned.
PHP devs repeatedly tell that Suhosin brings no additional value, while they clone and clone every time they are hit by a nasty bug.

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997

I'm sure we'd be more than happy to hear why it's broken and hear about
possible suggested fixes.

The purpose of the code is to detect all occurences of \r or \n not followed by whitespace and error out.
It is obviously doing something else.

Regards,
Stefan

13 years ago by Yasuo Ohgaki — view source — reply

unread

Hi,

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997

I'm sure we'd be more than happy to hear why it's broken and hear about
possible suggested fixes.

The purpose of the code is to detect all occurences of \r or \n not followed by whitespace and error out.
It is obviously doing something else.

Just looking at the patch. The comment in the code states

/* new line safety check */

but it cannot be a safety check as Stefan mentioned.
It should be fixed, if it was intended as security measure.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

2012/2/3 Stefan Esser stefan@nopiracy.de:

Hello Derick,

and most probably many more that I do not know from the top of my
head (this are already 9 features and Suhosin/HPHP exists since 2004 =
8 years).

Lots of stuff in PHP was also "stolen" from Xdebug, but I am not whining
about that as the goal is (and has always been) to make PHP better.

I am not whining of something being stolen I trying to demonstrate that a lot of the features noone ever saw a need for in PHP have been cloned.
PHP devs repeatedly tell that Suhosin brings no additional value, while they clone and clone every time they are hit by a nasty bug.

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997

I'm sure we'd be more than happy to hear why it's broken and hear about
possible suggested fixes.

The purpose of the code is to detect all occurences of \r or \n not followed by whitespace and error out.
It is obviously doing something else.

Regards,
Stefan

13 years ago by Stas Malyshev — view source — reply

unread

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

13 years ago by Thomas Goirand — view source — reply

unread

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)

13 years ago by keisial@gmail.com — view source — reply

unread

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.

13 years ago by Stefan Esser — view source — reply

unread

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:

http://www.hardened-php.net/hphp/faq.html#why_is_hardening-patch_not_part_of_php

https://bugs.php.net/search.php?search_for=suhosin&boolean=0&limit=90&order_by=&direction=DESC&cmd=display&status=All&bug_type=All&project=PHP&php_os=&phpver=5.3&cve_id=&assign=&author_email=&bug_age=0&bug_updated=0

https://bugs.php.net/bug.php?id=60216

https://bugs.php.net/bug.php?id=60935

http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/

You understand that Hardening-Patch is not Suhosin-Patch, do you?
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

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

13 years ago by Christoph Anton Mitterer — view source — reply

unread

Hey.

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

Suhosin patch has an impact on the speed and memory usage. This has
been documented and even author admits it [1].

It doesn't help our users when reporting bugs to upstream - the
usual answer is - try if that happens with vanilla php.

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.

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).

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?!

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.

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.

13 years ago by Florian Anderiasch — view source — reply

unread

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

13 years ago by Stefan Esser — view source — reply

unread

Hey Florian,

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.

people are constantly ignoring the fact that Suhosin-PHP listens to several environment variables:

SUHOSIN_MM_USE_CANARY_PROTECTION default = 1
SUHOSIN_MM_DESTROY_FREE_MEMORY default = 0
SUHOSIN_MM_IGNORE_CANARY_VIOLATION default = 0
SUHOSIN_HT_IGNORE_INVALID_DESTRUCTOR default = 0
SUHOSIN_LL_IGNORE_INVALID_DESTRUCTOR default = 0

By configuring these environment variables you can disable the canary protection that is "eating tons of memory and speed" (which is greatly exaggerated by people).
You don't need to have two compiled packages. You can just DISABLE Suhosin to 90% with these flags - or make it even stronger by telling it to sanitize all freed memory.

BTW: The Debian PHP maintainers know about these flags, because I repeatedly mentioned them in my answers to them. Also the Debian PHP maintainers patched the code of these environment variables 2 years back. So not knowing about them is just an excuse (if they bring it up).

Regards,
Stefan

13 years ago by Thomas Goirand — view source — reply

unread

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 think you are under estimating how much work Ondrej has done already
in the past, and how much more work you are asking him to do here,
when the whole PHP team is shouting for help! Yes, adding yet another
build is more work, not less.

Ondrej's post is mostly motivated by his lack of time (please, Ondrej,
correct
me if I'm wrong), and the fact that for him, continuing to maintain PHP with
Suhosin is difficult and time consuming (he made few points explaining why).

If Stefan was ready to help (or someone else), both in maintaining the
patch and extension in Debian, and also help with the packaging of PHP
itself, and with bug reports, triaging and such, it would be totally
different.

But as much as I can tell, neither Stefan or anyone else seem to be willing
to make the necessary efforts.

I've bring that up with Stefan, and yet didn't receive a reply from him on
this topic.

Thomas

13 years ago by Christoph Anton Mitterer — view source — reply

unread

Hey.

So what's the result of this discussion now?!

^^

Chris.

Suhosin patch disabled by default in Debian php5 builds

Cheers,

What the quality of the code of Joomla has to do with anything? Suhosin patches would not fix Joomla and most of the issues it helps with are totally unrelated to any user code at all.

Cheers,

Cheers,

-- Lester Caine - G8HFL

Cheers,

Cheers,

Cheers.

Cheers,

Cheers,

Cheers,

Cheers,

Cheers,

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.

What the quality of the code of Joomla has to do with anything? Suhosin
patches would not fix Joomla and most of the issues it helps with are
totally unrelated to any user code at all.

--
Lester Caine - G8HFL

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.