It was reported [1],[2] that there was an integer overflow in PHP's shmop_read() function. This function reads a given number of bytes from memory, at a given offset starting from a shared memory area. With a sufficiently large value, more memory is allocated than there is space for, which could result in a segfault because PHP is reading past its own memory. If there is enough allocated memory available, however, PHP could leak up to 2GB of arbitrary memory. To test: <?php $shm_key = ftok(__FILE__, 't'); $shm_id = shmop_open($shm_key, "c", 0644, 100); $shm_data = shmop_read($shm_id, 1, 2147483647); //if there is no segmentation fault past this point, we have 2gb of memory! echo $shm_data; ?> This sets a start value of 1, and 2^31 (2147483647) as the count: 2147483647+1 = -2147483647 This was corrected upstream [3] for version 5.3.6. References: [1] http://openwall.com/lists/oss-security/2011/03/08/9 [2] http://bugs.php.net/54193 [3] http://svn.php.net/viewvc/?view=revision&revision=309018
It looks as though you would need to allow very high amounts of memory to PHP in order to achieve a segfault here. Using the above test script on Red Hat Enterprise Linux 6: % php --version PHP 5.3.2 (cli) (built: Jan 19 2011 08:09:24) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies % egrep '^memory_limit' /etc/php.ini memory_limit = 1280M % php CVE-2011-1092.php PHP Fatal error: Allowed memory size of 1342177280 bytes exhausted (tried to allocate 2147483648 bytes) in /tmp/CVE-2011-1092.php on line 4 I've not yet had a chance to look at older versions.
Yes, memory_limit is 128M the RHEL 5/6 default configs (and lower in older versions). You can set to -1 to disable a limit for testing the script. It does not seem likely or reasonable that a script will pass untrusted and unvalidated script input data to the shmop_* functions, so I'd say there is no trust boundary being crossed here.
This is a duplicate. *** This bug has been marked as a duplicate of bug 169857 ***
Few additional notes: - The test case mentioned in comment #0 would not work on 64bit system such as x86_64 without changes. The shmop_read uses (signed) long type to store start and count parameter values. Test case passes INT_MAX as a count argument, to make bytes (== count) + 1 to overflow. This can only happen if start + count overflows in the following check: start + count > shmop->size That does not happen in this specific case on 64bit, as long can store 1 + INT_MAX without overflowing (int is 32bit, long is 64bit). However, it is possible to modify the test to trigger crash on 64 bit too, as count value is assigned to int bytes variable, where truncation to 32 bits can happen and can lead to a crash similar to the one seen on 32bit systems. - Additionally, that test case does not work on 32bit php packages in RHEL-4 and RHEL-5 (php-5.1.6, but it does work in php53-5.3.3), where PHP rejects memory allocations with negative size or size greater than INT_MAX. On 32bit only INT_MAX value incorrectly passes start and count checks, which leads to an attempt to allocate INT_MIN bytes, which is rejected. On 64bit, only 64bit LONG_MAX value incorrectly passes checks and leads to an attempt to allocate 0-sized buffer, which triggers the crash on subsequent memcpy.
Statement: Red Hat does not consider this to be a security issue. Input passed to these functions should be under the full control of the script author, thus no trust boundary is crossed. Additionally, an administrator would have to disable, or excessively increase the memory_limit settings in the PHP configuration file to trigger this bug.
This is marked as a duplicate of 169857 but that doesn't seem correct based on reading that bug. Also, comment 8 said that Red Hat doesn't consider this to be a security issue, but I would propose that it is because doesn't it allow an attacker increase the severity of an attack by gaining access to more data than they otherwise would have been able to get. For example, consider a Red Hat server that is being used for shared hosting and it has one client's site on it that gets compromised (such as because it's running out of date open source software like WordPress) such that the attacker can run arbitrary code on that site only. Now wouldn't they just call ini_set('memory_limit', '3000M'); in PHP code and thus be able to do the exploit and read other clients' data? An important point of note is that the memory_limit setting doesn't just get set by an administrator, it also can be set in PHP scripts as it's of type PHP_INI_ALL (see us2.php.net/manual/en/ini.core.php#ini.sect.resource-limits)