Home page logo

fulldisclosure logo 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)

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.

- ---------------------------------------------------------------------------
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
Version: GnuPG v1.2.3 (GNU/Linux)


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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]