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

From: Dan Margolis (
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" <>
    Date: Tue, 02 Nov 2004 15:28:23 -0500

    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.

    Version: GnuPG v1.2.4 (Darwin)

    -----END PGP SIGNATURE-----

    Full-Disclosure - We believe in it.

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