what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Jul 14, 2004
Authored by Stefan Esser | Site security.e-matters.de

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

tags | advisory, remote, php, code execution
advisories | CVE-2004-0594
SHA-256 | a2764c250202043b5e2fbcc945ecc7953565f046d5aa69d07e2cf18d05dc5ee3


Change Mirror Download
Hash: SHA1

e-matters GmbH

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


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

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.


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

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.


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.



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.

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

Login or Register to add favorites

File Archive:

September 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Sep 1st
    2 Files
  • 2
    Sep 2nd
    21 Files
  • 3
    Sep 3rd
    0 Files
  • 4
    Sep 4th
    17 Files
  • 5
    Sep 5th
    34 Files
  • 6
    Sep 6th
    29 Files
  • 7
    Sep 7th
    11 Files
  • 8
    Sep 8th
    25 Files
  • 9
    Sep 9th
    0 Files
  • 10
    Sep 10th
    0 Files
  • 11
    Sep 11th
    26 Files
  • 12
    Sep 12th
    23 Files
  • 13
    Sep 13th
    17 Files
  • 14
    Sep 14th
    22 Files
  • 15
    Sep 15th
    16 Files
  • 16
    Sep 16th
    0 Files
  • 17
    Sep 17th
    0 Files
  • 18
    Sep 18th
    19 Files
  • 19
    Sep 19th
    60 Files
  • 20
    Sep 20th
    23 Files
  • 21
    Sep 21st
    15 Files
  • 22
    Sep 22nd
    8 Files
  • 23
    Sep 23rd
    0 Files
  • 24
    Sep 24th
    0 Files
  • 25
    Sep 25th
    17 Files
  • 26
    Sep 26th
    3 Files
  • 27
    Sep 27th
    13 Files
  • 28
    Sep 28th
    5 Files
  • 29
    Sep 29th
    0 Files
  • 30
    Sep 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By