full-disclosure - How secure is PHP ?

lists.openwall.net		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 linux-hardening linux-cve-announce 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: krispykringle at gentoo.org (Dan Margolis)
Subject: How secure is PHP ?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gary E. Miller wrote:
> 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.

I am unaware of any, either. But there are some that merely require
*any* PHP script, irrespective of what functions or how poorly written
the script is. Well, this begs the question: if you don't intend to run
PHP scripts, why do you have PHP installed? :P

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

It is analogous. That's exactly my point; that as a developer, one
should be able to make various assumptions about the safety of provided
functions (that striptags will really strip all tags, for instance, or
that a file upload will really upload to where you told it to, or that
enabling limitations on the size of POST data will not result in remote
code execution); if those functions are unsafe, they should not be
provided.

So as I said, the issue is not with insecure PHP programs, but with the
PHP engine and libraries themselves. This is not to say that one must
not be running PHP scripts--sometimes even scripts with specific
functions or using specific libraries--in order to be vulnerable, but
like I said, it's a safe assumption, if one has PHP installed, that he
is running PHP scripts.

> "Strong typeing is for weak minds" :-)

Cute.

Have you ever written code with a security flaw? Ever? :P

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

I didn't come to debate languages, and I fully agree that PHP can be
used publicly in relative safety. I just wanted to dispell the notion
that the only vulnerabilities derive from poorly written code, and that
a good developer who uses PHP according to specifications has nothing to
worry about. Clearly, as I pointed out above, that is not always the case.

If you'd like to discuss the relative merits of PHP further, I'd
actually be glad to, but I'd rather do it off-list (my primary
complaints focus more on the cleanliness of PHP as a
language--inconsistencies in naming conventions, the unnecessarily vast
number of built-in functions in the global namespace, inconsistencies in
argument order, multiple built-in functions that perform the same
function but have different usage, etc).

Cheers,
Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQZOlIbDO2aFJ9pv2AQL+SwgA2pm/nAuTUdL2uvnknticseMBCNtUbcYp
omY6r8XrlwCDFBNycaB6PRsJgeis2oPIEmxvzMJJTYWpWg0+Vz0/FXnSyQL0A2dl
66TlOiMrrp8bEyRMFaBNRBdMJH9BHavHs5mNCNyDmBN+aD+IqvCRViVbxFsqKm3x
CrTTAE6J5X0XBp9+z+J4LpvnW4diUkWqEbB6lWbtYofoJTQHiVlKawJjbcx7sEPZ
/JJLYg8Egbo3ZM143V1avEqkH1ejKtGJ8zgQsOyNBT6pqGKiBiGrNJTYu1v8K3VK
mZe5DJXvc3ZQhoyUsit422eAbMqWzLp7KEyGV/7FKm8AzAeCdpkybw==
=3mRz
-----END PGP SIGNATURE-----