On Tue, Oct 29, 2002 at 03:35:22PM +0000, Paul Makepeace wrote:
> I'd read this as FUD, frankly, until you can show PHP has suffered
> vulnerabilities so severe as to require shutting down service "every
> few weeks".
> This might seem anal of me but people might actually take what you're
> saying to heart and then continue to spread disinformation. If a package
> deserves commentary like that (say MS not fixing reported bugs for after
> several weeks of being notified), fair enough, if it doesn't, it's worth
> IMO avoiding hyperbole.
I read what you're saying, and I'm unlikely to support PHP on my server
for similar reasons to Roger. Chris Andrews, who reads this list[1], can
probably explain better, as he has to deal with user support for PHP. In
essence, however, it seems to be very easy to write PHP in a way that it
silently eats errors, fails to quote appropriately, and other such things,
and much harder to write PHP of a quality that will withstand serious
attempts against it.
[1] and also happens to be the real owner of the lusercop.net domain name,
no, he's not me, as you well know
Now, admittedly, this does come down in a big way to the experience level
of the ``programmer'' (and I use that word carefully) who writes the PHP,
as often they are not aware of the way in which failures can be exploited
and not really that interested in the consequences (which may end up
backfiring on you as a server administrator). An example of this might be
a script that used the mail function in such a way as to be an http-based
open relay. This will rapidly get you blacklisted if noticed and exploited,
and many people say "well, they'll never notice me, why will they pick on
me?". Due to the apparent difficulty in appropriately quoting for HTML, a
lot of people don't realise that this is necessary, and end up with Cross-
Site Scripting, which while not a "real" vulnerability is potentially nasty
if combined with a cookie-based authentication system.
I can see that it depends how much you care, and who is supporting the PHP
application. My system allows users to run their own CGI's, though I think
that those who will take advantage of this feature are either a) clueful
enough to write them sensibly or b) able to ask me to check for possible
holes. It is then their account which is at stake. PHP has access to all
the other PHP applications in a normal setup (in much the same way as, say,
mod_perl) and has the same security issues. If it matters to you that a
user can write to files that your system-supported PHP application is
attempting to maintain, then this would be bad. In my system, I would
consider that to be undesirable.
I think my conclusion for all of this is that I can't trust PHP, because
architecturally, it appears to be designed for use in situations where the
necessity is not for any kind of privilege management, or separation. It
appears to be designed to get dynamic pages up and running as quickly as
possible and as easily as possible. This tends to attract the people who
don't understand the implications of the way they write their code, as a
result of the ease of use. It's very easy to positively test something,
much harder to negatively test it.
--
Lusercop.net - LARTing Lusers everywhere since 2002
