MOPB-15-2007:PHP shmop Functions Resource Verification Vulnerability

Summary

The shared memory (shmop) functions fail to verify the type of the resource that is used when they are called from PHP. Therefore it is possible to call them with a wrong resource type that might contain user supplied data. By for example using a special prepared GD Image resource it is possible to read and write to arbitrary memory addresses with the shmop functions.
Affected versions

Affected are PHP < 4.4.5 and PHP < 5.2.1
Detailed information

PHP functions that have to deal with (request) persistent structures should register resources with the Zend Engine and return them instead of returning pointers to the used structures in memory, because PHP scripts should be completely separated from raw memory.

The shmop functions use such resources to store information about shared memory segments, for example the base address where it is mapped and its length. When PHP scripts access shared memory through these functions it is first verified that the supplied parameters are in the bounds defined by the resource.

Unfortunately the functions fail to verify that the resource supplied are really shmop resources and therefore the functions can be tricked to access arbitrary memory addresses by calling them with resources generated by other means. The easiest exploit uses the GD Image resource type, because in those it is possible to influence the pointers shmop uses by simply manipulating the Image palette. This allows to supply any base address for shared memory segments and therefore read and write access to the whole address space from within a PHP script. This obviously can be exploited to execute arbitrary code.
Proof of concept, exploit or instructions to reproduce

Attached are two exploits. The first demonstrates how the shmop functions can be used to read and write arbitrary memory addresses to execute arbitrary code and the second exploit should be copied onto an Apache server that uses mod_php and mod_ssl. When the exploit is called it will scan the Apache memory (tested on Apache 1 + linux + x86) for the private RSA key of the SSL certificate and provide it as a downloadable file.
Notes

This vulnerability is a perfect example why a local PHP vulnerability can be dangerous. Scanning the Apache memory for the private RSA key is something that a PHP script cannot do.

And even when every PHP script runs in a separate process with a separate user an attacker can do a lot more with plain machine code (through a PHP exploit) than with a PHP script alone