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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4187EDE7.1070508@gentoo.org>
From: krispykringle at gentoo.org (Dan Margolis)
Subject: How secure is PHP ?

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

Gary E. Miller wrote:
> Saying PHP in insecure is like saying C is insecure.  Until their is
> a programmer involved, writing bad code, there is no problem.  Just like
> C if the programmer carefully validates and contrains ALL input then
> the program is not only secure but robust.

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

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.

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

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

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

iQEVAwUBQYft57DO2aFJ9pv2AQKecAgAmPosM4ohQkojnta1rQwjgqtN5/oD8mZM
rShQDEG3RdgMk1E0xjb00VePC/rGSvkxgjyXfUhU4cN8sIEgaaiYTm9IJpFEalaI
NEKiw6jjHoWvlnJ28RvhObbNEFDB/55AbbQoM00JcSGn96hDkUTy8Exz2jqU42Pw
8VlGdzQ7RbMTX7T350iScsXnba8FCmfEvFklJBIv2baX3p8WUviosyuHta6vXXXe
kbKmalqZXFWQKQBqOtQvAQpb9HPAwqxSZBJsChalkX/8r3ZMW48RMfYJrc+ktkSW
TezJebBpKjRxwfwwWP4PbVldBfR/84MBBX0ES8STC5sjaYSLBgPSUw==
=SuV/
-----END PGP SIGNATURE-----