Message-ID: <Pine.GSO.4.43.0411040029580.15303-100000@parka.winternet.com>
From: dufresne at winternet.com (Ron DuFresne)
Subject: How secure is PHP ?

On Tue, 2 Nov 2004, Gary E. Miller wrote:

	[SNIP]

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

	[SNIP]


I'm not sure php is all that safe for public consumption as you sir.  A
quick look at security focus, searching the vuln db for PHP, nothing more
comes up with this history;

         2004-10-28:    PHP cURL Open_Basedir Restriction Bypass
Vulnerability
         2004-10-25:    PHP Remote Arbitrary Location File Upload
Vulnerability
         2004-10-25:    PHP PHP_Variables Remote Memory Disclosure
Vulnerability
         2004-10-16:    PHP memory_limit Remote Code Execution
Vulnerability
         2004-09-15:    PHP Strip_Tags() Function Bypass Vulnerability
         2004-06-07:    PHP Microsoft Windows Shell Escape Functions
Command
Execution Vulnerability
         2004-05-27:    PHP Input/Ouput Wrapper Remote Include Function
Command
Execution Weakness
         2004-03-24:    PHP openlog() Buffer Overflow Vulnerability
         2003-11-07:    PHP emalloc() Unspecified Integer Overflow Memory
Corruption Vulnerability
         2003-11-07:    PHP wordwrap() Heap Corruption Vulnerability
         2003-09-24:    PHP4 Multiple Vulnerabilities
         2003-09-24:    PHP4 Base64_Encode() Integer Overflow
Vulnerability
         2003-08-25:    PHP Transparent Session ID Cross Site Scripting
Vulnerability
         2003-08-13:    PHP Mail Function ASCII Control Character Header
Spoofing Vulnerability
         2003-08-13:    PHP Function CRLF Injection Vulnerability
         2003-08-13:    PHP DLOpen Memory Disclosure Vulnerability
         2003-07-17:    PHP Undefined Safe_Mode_Include_Dir Safemode
Bypass
Vulnerability
         2003-06-08:    PHP STR_Repeat Boundary Condition Error
Vulnerability
         2003-06-08:    PHP array_pad() Integer Overflow Memory Corruption
Vulnerability
         2003-06-04:    PHP PHPInfo Cross-Site Scripting Vulnerability
         2003-05-19:    PHP Post File Upload Buffer Overflow
Vulnerabilities
         2003-05-07:    PHP SafeMode Arbitrary File Execution
Vulnerability
         2003-04-14:    PHP MySQL Safe_Mode Filesystem Circumvention
Vulnerability
         2003-03-26:    PHP socket_recvfrom() Signed Integer Memory
Corruption
Vulnerability
         2003-03-26:    PHP socket_recv() Signed Integer Memory Corruption
Vulnerability
         2003-03-25:    PHP socket_iovec_alloc() Integer Overflow
Vulnerability
         2003-02-19:    PHP CGI SAPI Code Execution Vulnerability
         2003-01-08:    PHP 4.0.3 IMAP Module Buffer Overflow
Vulnerability
         2002-09-07:    PHP Header Function Script Injection Vulnerability
         2002-08-08:    PHP HTTP POST Incorrect MIME Header Parsing
Vulnerability
         2002-07-22:    PHP Interpreter Direct Invocation Denial Of
Service
Vulnerability
         2002-04-25:    PHP posix_getpwnam / posix_getpwuid safe_mode
Circumvention Vulnerability
         2002-03-21:    PHP Move_Uploaded_File Open_Basedir Circumvention
Vulnerability
         2002-02-08:    PHP Include File Relative Directory Information
Disclosure Vulnerability
         2002-01-15:    PHP4 Session Files Local Information Disclosure
Vulnerability
         2001-01-16:    PHP .htaccess Attribute Transfer Vulnerability
         2001-01-12:    PHP Engine Disable Source Viewing Vulnerability
         2000-10-12:    PHP Error Logging Format String Vulnerability
         2000-09-03:    PHP Upload Arbitrary File Disclosure Vulnerability
         2000-01-04:    PHP3 'safe_mode' Failure Vulnerability
         1999-06-01:    PHP/FI Buffer Overflow Vulnerability
         1999-06-01:    PHP/FI mylog/mlog Vulnerability
         1999-06-01:    PHP/FI Directory Traversal Vulnerability


And this is listed for PHP itself, not the 74 additional modules or apps
that are listed there on security focus as well.  Most of those '74'
appear in weekly or bi-weekly announcments to the various vuln/seclists.
I get the impression that not only is PHP not fully matured for mortals,
perhaps it's too unweildly for the light at heart coders that dominate
web-space. It certainly appears to not belong anyplace but in the DMZ
sacrificial lamb, and is like sendmail or wu_ftp of the 1990's.

You make the point though that php installed and embedded within httpd is
in and of itself *safe*, that it takes 'code' to make it vulnerable.  And
this might well be the case, but, one has to question, if the base is
unstable, and is not going to be used, then why install it in the first
place?


Thanks,


Ron DuFresne
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.

Powered by blists - more mailing lists