lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: gem at (Gary E. Miller)
Subject: How secure is PHP ?

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  Tel:+1(541)382-8588 Fax: +1(541)382-8676
Version: GnuPG v1.2.3 (GNU/Linux)


Powered by blists - more mailing lists