From: gem at rellim.com (Gary E. Miller)
Subject: How secure is PHP ?

-----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@...lim.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-----

Powered by blists - more mailing lists