full-disclosure - How secure is PHP ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.GSO.4.43.0411181615110.9781-100000@tundra.winternet.com>
From: dufresne at winternet.com (Ron DuFresne)
Subject: How secure is PHP ?

On Thu, 4 Nov 2004, Stefan Esser wrote:

> Nice try Ron,
>
> while PHP indeed had lots of advisories in the past, your
> list is FUD.

It's not *my* list, just happens to be the list I grabbed for context to
this thread.  The list was compliled over the years on security focus, I
claim no ownership! <smile>.

>
> Many of the listed vulnerabilities are within non standard
> or even EXPERIMENTAL extensions, are theoretical vulnerabilities,
> are only exploitable if precondition a,b,c,d,e,f,g is fullfilled
> or are only affecting the windows platform.
>

Look, even if as you say many are either requiring other specifics to be
sploited, that does not cover all, and even if the remaining have been
corrected at present, this still leaves php with a poor track record over
a shrt span of time.  And this does not even cover the point I infered
about there being, what did I mention earlier, like 74 php modules or
applications also listed in the same database with their own distinct
issues, some popping into context weekly or bi-weekly to these lists.  Now
as Gary wished to infer, "the problem is not php, it's the code, having
php as a apache module in and of itself does not make the website
sploitable", sure, this might be a fact at present, merely having the php
module running and not code present might not be a risk for what has been
so far discovered with php. But, why would one have a dead module running
under their httpd?  Now, let's imagine that for all intents and purposes
that all issues with php itself have been found and released and fixed.
Then I still hold to my statement that for the vast majority of folks who
do web apps and html tagging, php is far too;

it's too unweildly for the light at heart coders that dominate
web-space.

Gary might well be that special php coder that always creates secure code,
perhaps you yourself fall into that space as well, that still leaves an
estimated 75% or more of all web applications in security muck <I know not
all are written in php> so if the base problem is all in the code, after
working out the interpreteres issues, then php still falls into a realm
I'm not putting anyplace but on my DMZ's, and not letting it pass inside
the perimiter, sorry.  The vast majority of web application coders are not
up to the task.

Thanks,

Ron DuFresne
-- 
"Sometimes you get the blues because your baby leaves you. Sometimes you get'em
'cause she comes back." --B.B. King
        ***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.