PHP new vulnarabilities

[Paul Schmehl]

--On October 15, 2006 4:31:48 PM -0400 DAve <dave.list at pixelhammer.com> 
wrote:
>
> That is a bit extreme. I have a full workload, I put in about 60 hours a
> week (I work a lot of weekends, I'm working now). I have servers running
> all different version of apps. I can't go around upgrading everything at
> the drop of a hat. I would be divorced within a month.
>
> If you read the security alerts carefully you will find many require a
> shell (We don't offer them to clients), some require a specific app to
> be running that you may not need (rm -f /usr/local/bin/vulnerable_app),
> and sometimes a simple code audit will tell you if you are vulnerable.
> It is also not uncommon that a security alert is issued for a problem
> that has not be proven in the wild.
>
> There are plenty of reasons to not follow a security alert, many of them
> quite valid. Upgrading mission critical systems without throughly
> understanding the implications just because someone screamed SECURITY!,
> now that is foolhardy.
>
That wasn't the situation here.

Look, there are several possible scenarios where installing a vulnerable 
app is less of a risk than not installing the app at all.  Business 
functionality *is* important.  However, to arbitrarily say "Use 
DISABLE_VULNERABILITIES" is the answer to an app that won't install is 
always a wrong answer.  *At a minimum* it should come with a warning of 
the possible risks.  Furthermore *upgrading* from a non-vulnerabile app to 
a vulnerable app simply because "it's the latest" is foolhardy in the 
extreme.

I don't think my statement was any more extreme than "Just use 
DISABLE_VULNERABILITIES and you can install the app" with no warning of 
the risks.  *Especially* when the app is as highly scrutinized as php is 
(not to mention how vulnerabilities are being found in it all the time.)

Paul Schmehl (pauls at utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/