‘Multiple Vulnerabilities within PHP 4/5 (pack, unpack, safe_mode_exec_dir, safe_mode, realpath, unserialize)’
‘PHP is ‘a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML’.
* PHP4 version 4.3.9 and prior
* PHP5 version 5.0.2 and prior
1. pack() – Integer Overflow Leading to Heap Buffer Overflow
Insufficient validation of the parameters passed to pack() can lead to a heap overflow which can be used to execute arbitrary code from within a PHP script. This enables an attacker to bypass safe_mode restrictions and execute arbitrary code with the permissions of the web server. Due to the nature of this function it is unlikely that a script accidentally exposes it to remote attackers.
2. unpack() – Integer Overflow Leading to Heap Info Leak
Insufficient validation of the parameters passed to unpack() can lead to a heap information leak which can be used to retrieve secret data from the apache process. Additionally a skilled local attacker could use this vulnerability in combination with (1) to bypass heap canary protection systems. Similar to (1) this function is usually not used on user supplied data within web applications.
3. safe_mode_exec_dir bypass in Multithreaded PHP
When safe_mode is activated within PHP, it is only allowed to execute commands within the configured safe_mode_exec_dir. Unfortunately PHP does perpend a ‘cd [currentdir] ;’ to any executed command when a PHP is running on a multi-threaded UNIX web server (f.e. some installations of Apache2). Because the name of the current directory is perpended directly a local attacker may bypass safe_mode_exec_dir restrictions by injecting shell commands into the current directory name.
4. safe_mode Bypass Through Path Truncation
The safe_mode checks silently truncated the file path at MAXPATHLEN bytes before passing it to realpath(). In combination with certain malfunctioning implementations of realpath() f.e. within glibc this allows crafting a filepath that pass the safe_mode check although it points to a file that should fail the safe_mode check.
5. Path Truncation in realpath()
PHP uses realpath() within several places to get the real path of files. Unfortunately some implementations of realpath() silently truncate overlong filenames (f.e. OpenBSD, and older NetBSD/FreeBSD). This can lead to arbitrary file include vulnerabilities if something like ‘include ‘modules/$userinput/config.inc.php’; is used on such systems.
6. unserialize() – Wrong Handling of Negative References
The variable unserializer could be fooled with negative references to add false zvalues to hash tables. When those hash tables get destroyed this can lead to efree()s of arbitrary memory addresses that can result in arbitrary code execution. (Unless Hardened-PHP’s memory manager canaries are activated)
7. unserialize() – Wrong Handling of References to Freed Data
Additionally to bug (7) the previous version of the variable unserializer allowed setting references to already freed entries in the variable hash. A skilled attacker can exploit this to create an universal string that will pass execution to an arbitrary memory address when it is passed to unserialize(). For AMD64 systems a string was developed that directly passes execution to code contained in the string itself.
It is necessary to understand that these strings can exploit a bunch of popular PHP applications remotely because they pass f.e. cookie content to unserialize().
Examples of vulnerable scripts:
– Invision Board
– Woltlab Burning Board 2.x
– Serendipity Weblog
It is strongly recommended to upgrade to the new PHP-Releases as soon as possible, because a lot of PHP applications expose the easy to exploit unserialize() vulnerability to remote attackers. Additionally we always recommend to run PHP with the Hardened-PHP patch applied.’