Re: [Full-Disclosure] How secure is PHP ?

From: Dan Margolis (krispykringle_at_gentoo.org)
Date: 11/02/04

  • Next message: morning_wood: "Re: [Full-Disclosure] MSIE <IFRAME> and <FRAME> tag NAME property bufferoverflow PoC exploit (was: python does mangleme (with IE bugs!))"
    To: "Gary E. Miller" <gem@rellim.com>
    Date: Tue, 02 Nov 2004 15:28:23 -0500
    
    

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Gary E. Miller wrote:
    > Saying PHP in insecure is like saying C is insecure. Until their is
    > a programmer involved, writing bad code, there is no problem. Just like
    > C if the programmer carefully validates and contrains ALL input then
    > the program is not only secure but robust.

    That's not strictly correct. Having PHP installed on a web server can
    introduce vulnerabilities, regardless of whether PHP scripts running are
    vulnerbale, but having a C compiler installed would probably not
    introduce vulnerabilities (other than the ability to compile and run
    exploits for that architecture).

    In early October, there was a PHP vulnerability that allowed arbitrary
    file uploading and the disclosure of memory contents; in mid July there
    were a handful of PHP vulnerabilities disclosed that could allow remote
    code execution through the exploit of buffer overflows in PHP itself.

    In other words, these were vulnerabilities not in poorly-written PHP
    scripts, but in the PHP engine itself that, regardless of scripts
    installed or not installed, could allow a remote attacker (in the case
    of the latter) to execute arbitrary code with the permissions of the
    process running PHP (the webserver).

    Additionally, on a more abstract note, I think it is unwise to be
    cavalier about concerns about specific languages (like C); if it is
    possible to achieve a given task with a ``safer'' language, that is
    probably a wise decision--humans make mistakes. Using a language like
    Java or Python that supports array bounds checking can be an excellent
    way to avoid needless buffer overflows in applicable uses, and just so,
    using a server-side scripting language that makes it more difficult to
    write insecure code can be a great way of avoiding
    programmer-error-induced vulnerabilities. Someone has already written
    array bounds checking and input sanitation, for the compilers or
    libraries or runtime interpreters of these languages; there is no reason
    for every programmer out there to start with C and re-invent the wheel.

    Cheers,
    Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (Darwin)

    iQEVAwUBQYft57DO2aFJ9pv2AQKecAgAmPosM4ohQkojnta1rQwjgqtN5/oD8mZM
    rShQDEG3RdgMk1E0xjb00VePC/rGSvkxgjyXfUhU4cN8sIEgaaiYTm9IJpFEalaI
    NEKiw6jjHoWvlnJ28RvhObbNEFDB/55AbbQoM00JcSGn96hDkUTy8Exz2jqU42Pw
    8VlGdzQ7RbMTX7T350iScsXnba8FCmfEvFklJBIv2baX3p8WUviosyuHta6vXXXe
    kbKmalqZXFWQKQBqOtQvAQpb9HPAwqxSZBJsChalkX/8r3ZMW48RMfYJrc+ktkSW
    TezJebBpKjRxwfwwWP4PbVldBfR/84MBBX0ES8STC5sjaYSLBgPSUw==
    =SuV/
    -----END PGP SIGNATURE-----

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html


  • Next message: morning_wood: "Re: [Full-Disclosure] MSIE <IFRAME> and <FRAME> tag NAME property bufferoverflow PoC exploit (was: python does mangleme (with IE bugs!))"