[vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?

[Rick Moen]

Quoting Dr. Larry Ozeran (lozeran at clinicalinformatics.com):

> Thanks Rick.
> 
> This is why I have such great respect for the members of this list.
> You have such valuable experiences that you are willing to share. I
> regret that I have had the experience of server issues occurring at
> bad times (right after talking about our product at a trade event),
> but thus far none have been PHP or MySQL related, so I very much
> appreciate the insights of others.

Looking over my notes about tightening PHP security (direct link
http://linuxmafia.com/faq/Security/php.html), I see something I might
consider writing more about  (in that piece):  I talk about several
prototype files Debian provided for /etc/php5/apache2/php.ini ,
specifically:

/usr/share/doc/php5-common/examples/php.ini-paranoid
/usr/share/doc/php5-common/examples/php.ini-recommended

The thing is, the distribution-provided  /etc/php5/apache2/php.ini 
file stated in header comment lines... well, let me just quote it:

;;;;;;;;;;;;;;;;;;;
; About this file ;
;;;;;;;;;;;;;;;;;;;
; PHP comes packaged with two INI files. One that is recommended to be used
; in production environments and one that is recommended to be used in
; development environments.

; php.ini-production contains settings which hold security, performance and
; best practices at its core. But please be aware, these settings may break
; compatibility with older or less security conscience applications. We
; recommending using the production ini in production and testing environments.

; php.ini-development is very similar to its production variant, except it's
; much more verbose when it comes to errors. We recommending using the
; development version only in development environments as errors shown to
; application users can inadvertently leak otherwise secure information.


So, thing is, I could swear that the _default_ php.ini Debian installed
to /etc/php5/apache2/php.ini was the _development_ variant -- because
when I got around to looking through it and locking it down, I was a bit
shocked at the high default security exposure.  It was exactly as I was
working through that file, commenting out dangerous and unneeded
optional interpreter features, that I wrote my modest hardening guide
(more as notes for my own benefit than with any intent to publish).

That experience was one of my first signs that something was not right
with PHP and its security posture.  It might be my imagination, but 
I think part of what's happening is that only lip service is normally
given to enabling only the language functionality actually necessary; 
that many developers of PHP developed applications blithely expect 
deploying sites to have the kitchen-sink set of language functions
available and their code mysteriously fails if you don't.  So, deploying
sites are passively led into bad habits and bad defaults.

And, for example, picture a world where the developers gravitate towards
php.ini-development and sysadmins towards php.ini-production.  What's
going to happen as a natural tendency?  You know developers; they'll
happily use the features in front of them, which then will ratchet up
the need for those in deployment.  Not good.  It's a bad sign when the
development default environment includes bad security and the attitude
is 'be unsafe only while developing code and we'll fix it all up later'.

A brief clarification:  The incursion that happened just as I got on an
ocean cruise this past February happened _despite_ all the security
tightening, on account of yet another grave flaw in the core mod_php
code.  (I cannot tell you which flaw because I elected to just disable
the thing rather than work further on it.)