Full Disclosure mailing list archives
Re: How secure is PHP ?
From: "Gary E. Miller" <gem () rellim com>
Date: Tue, 2 Nov 2004 16:09:30 -0800 (PST)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Dan! On Tue, 2 Nov 2004, Dan Margolis wrote:
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).
I guess I mostly agree. PHP is usually bolted into the running Apache and so can add problems by just being there. This is NOT always the case. Debian by default installs it as a standalone module that is only called if a .php file exists to be called as a cgi-bin. If you are truly paranoid then use it that way. I am unaware of ANY php bug that has not required a preexisting server side php program to be explioted. If I am wrong please enlighten me.
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.
I am unaware of any that could be exploited without corresponding PHP code on the server side using those functions. So just having PHP installed was not sufficient to be vulnerable. If you have some specifics to prove me wrong I would appreciate some clues from you so I can look it up.
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).
I see this as exactly analogous to the recently found libgd bugs. If you had a C program or a PHP program that called libgd then you had a problem. This is a problem in the function library not in the language per-se. Since PHP and C heavily share the same libaries they will heavily share the same vulnerabilities.
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.
"Strong typeing is for weak minds" :-)
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.
This would be a plus for PHP over C. PHP has a fairly well done object managaement and garbage collection, unlike C. OTOH, C is a LOT easier to audit than Java, more portable and a LOT faster. Python is just too marginalized to be usefull on the web, it is much more developed in the numerical analysis sector. Regardless of the merits of C, Java, Perl, Python, etc. the bulk of available tools for Apache are now leaning towards PHP. If you want a particular widget for your webserver it is likely available in PHP, maybe in C or Perl and occasionaly in Java or Python. The market has decided. Grab some open source and away we go. So the only question should be is whether PHP is sanitary enough for a public server and that is clearly a yes. Plus the maintainers have been very responsive to security bugs. Known PHP holes do not stay open for long.
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.
Ultimately any high usage PHP program should be migrated to C, but PHP sure beats C in a rapid prototyping environment. Newer versions of PHP have the input sanitation as part of the core language, unlike C which requires add-ins. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem () rellim com Tel:+1(541)382-8588 Fax: +1(541)382-8676 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBiCG98KZibdeR3qURApinAKCXp6wRkxyoHzDXxHAUfHq2p/Ii8QCg6ZXW l9qXcm3ms9eNCxOlgy6U934= =WXLx -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- How secure is PHP ? Nayana Somaratna (Nov 01)
- Re: How secure is PHP ? ph0enix (Nov 01)
- Re: How secure is PHP ? Gary E. Miller (Nov 01)
- Re: How secure is PHP ? Dan Margolis (Nov 02)
- Re: How secure is PHP ? Gary E. Miller (Nov 02)
- Re: How secure is PHP ? Ron DuFresne (Nov 04)
- Re: How secure is PHP ? Stefan Esser (Nov 04)
- Re: How secure is PHP ? Ron DuFresne (Nov 22)
- Re: How secure is PHP ? Gary E. Miller (Nov 04)
- Re: How secure is PHP ? Dan Margolis (Nov 02)
- Re: How secure is PHP ? Dan Margolis (Nov 11)
- <Possible follow-ups>
- RE: How secure is PHP ? Sandeep Sengupta (Nov 01)
- Re: How secure is PHP ? Meder Kydyraliev (Nov 01)
- Re: How secure is PHP ? J b (Nov 04)