[ale] Well, this does nothing for the reputation of Linux

[Michael B. Trausch]

On 07/21/2013 04:44 PM, Andy Borgmann wrote:
> Where do you see this being a PHP non-security.  It sounds like it was
> an updated version of vBulletin's admin panel that had a security
> flaw.  Even if vBulletin is coded in PHP, I don't see why blaming PHP
> as a whole is warranted in this case and not just vBulletin.  PHP
> seems secure enough or Facebook.

Some points:

 1. Facebook does not run the official PHP, they run a subset of it that
    is then compiled, if memory serves, to C++ and then compiled to
    system code.
 2. PHP itself is insecure for *many* reasons, the least of which:
     1. PHP has never deprecated functionality that is known-unsafe,
        given the average experience of the PHP-only programmer; for
        example, SQL injection attacks are pandemic in PHP code not
        because it's any less safe than C, but because it is just as
        safe as C and PHP-only programmers don't have perspective from
        which to draw from to secure their own code.  This flaw could be
        fixed in PHP by removing functions that permit it; in my book,
        that makes it a PHP flaw (it's easier to fix PHP than it would
        be to fix all PHP programmers).
     2. PHP has a large number of pseudoprogrammers that work with it. 
        These people are mostly management types that found that they
        can quickly piece together a PHP script and make it do something
        useful.  These people have no background in security,
        information technology, information systems or any similar such
        topic.  They often C&P pathologically, and the systems that they
        create are swiss cheese from a security perspective.  Again,
        this is something that can be fixed in PHP, by ensuring that
        variables that come from the user are always represented in a
        canonical format and that outputs are properly escaped.
     3. PHP has a large number of what I call "auto-fsck-you" features
        built-in to it that most people do not understand.  One such
        example is PHP's associative arrays, which are really integer
        arrays. The reason that integers and string keys can both be
        used in PHP in the same array is that they share the same
        namespace; a very large sequential array is quite likely to
        clash with the hashed namespace used for string keys.  Fun,
        yes?  And that's just one example.

I could go on for pages, but there are many others who have done so at
length; I won't reinvent the wheel here.  I can say, though, that a
quick review of US-CERT data shows that PHP and applications written in
it are still among the most common of security problems---even in
systems written by professional programmers.

-- 
Naunet Corporation Logo 	Michael B. Trausch

President, *Naunet Corporation*
? (678) 287-0693 x130 or (888) 494-5810 x130

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/d471ffd8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jcdjeaha.png
Type: image/png
Size: 1701 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/d471ffd8/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mail.ale.org/pipermail/ale/attachments/20130722/d471ffd8/attachment-0001.sig>