PHP new vulnarabilities
pauls at utdallas.edu
Sun Oct 15 14:08:56 PDT 2006
--On October 15, 2006 4:31:48 PM -0400 DAve <dave.list at pixelhammer.com>
> 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
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
More information about the freebsd-questions