As topic said mini, it is mainly my idea (+some code) to exploit this bug. I still cannot do real code execution now. Looking at diff patch, it is obvious there is a bug when input is array and the number of input equals max_input_vars. Here is full vulnerable function. I will show only related code.
/* ... */
if (is_array) {
while (1) {
/* ... */
if (zend_symtable_find(symtable1, escaped_index, index_len + 1, (void **) &gpc_element_p) == FAILURE // [1]
|| Z_TYPE_PP(gpc_element_p) != IS_ARRAY) { // [2]
if (zend_hash_num_elements(symtable1) <= PG(max_input_vars)) { // [3]
if (zend_hash_num_elements(symtable1) == PG(max_input_vars)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Input variables exceeded %ld. ...", PG(max_input_vars));
}
MAKE_STD_ZVAL(gpc_element);
array_init(gpc_element);
}
zend_symtable_update(symtable1, escaped_index, index_len + 1, &gpc_element, sizeof(zval *), (void **) &gpc_element_p);
}
/* ... */
symtable1 = Z_ARRVAL_PP(gpc_element_p); // [4]
/* ... */
goto plain;
}
} else {
plain_var:
MAKE_STD_ZVAL(gpc_element);
gpc_element->value = val->value;
Z_TYPE_P(gpc_element) = Z_TYPE_P(val);
/* ... */
if (zend_hash_num_elements(symtable1) <= PG(max_input_vars)) { // [5]
if (zend_hash_num_elements(symtable1) == PG(max_input_vars)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Input variables exceeded %ld. ...", PG(max_input_vars));
}
zend_symtable_update(symtable1, escaped_index, index_len + 1, &gpc_element, sizeof(zval *), (void **) &gpc_element_p); // [6]
} else {
zval_ptr_dtor(&gpc_element);
}
/* ... */
}
At [3], if a number of elements in array equals max_input_vars, program still continues looping. When program reachs [4], the 'gpc_element_p' is treated as array (no type check). But it might not be array if the program did not go inside [3]. That is a problem.
When looking closely at [1] and [2], the code at [1] might find the element but it is not array. The element must be string because all input are treated as string or array. Also the element is our input that parsed before the max_input_vars condition met. Then At [4], our string is treated as array. So we can create fake HashTable. If our input name does not have more array nest, the PHP will go to [5]. Then inserting/updating input into fake array at [6].
To control EIP/RIP, there is 'pDestructor' in HashTable struct. If we can make PHP removing a element inside this HashTable, the program will jump to 'pDestructor' address. Easy??. All we need is 'arBuckets' must point to valid address that has NULL value (check _zend_hash_index_update_or_next_insert() in zend_hash.c).
Because PHP filter extension is enabled by default (compile option), the php_register_variable_ex() is called twice for each input but different array. So first time for filter array, the input is inserted into fake array. Then the array is updated and 'pDestructor' will be called. Below is input for controlling EIP/RIP.
1=&2=&3=&...&999=&0=<fake HashTable with valid arBuckets address>&0[0]=
Because of ASLR+NX(+PIE), just controlling EIP is useless. I need some info leak. Here is my result for 32 bit only (php_rce_poc.py) (I debugged the PHP with PHP-FPM).
First, there is some PHP page on server that has code like this.
<?php
echo $_POST['a']."\n";
for ($i = 0; $i < 8192; $i++)
echo " "; // to make PHP flush the buffer output
When input is inserted into array, a HashTable will be updated. We can use this fact to leak a heap address. But the trigger input will be inserted for filter array first, so the input will be updated for $_POST array. This is bad because updating is modified only 'pDataPtr' in 'Bucket' struct.
What I did is creating fake HashTable, arBuckets, Bucket in an input instead of HashTable only. If I guess the address correctly, the 'pDataPtr' in fake Bucket will be updated. To increase the chance, I create multiple fake arBuckets and Buckets (see create_big_fake_array_search() in my code). When allocating big memory block, it is always allocated outside main heap (And address always ending with 0x018 on my box). After this brute forcing, I got the start address of fake data and a heap address of latest element.
Just a heap address is not enough for code execution. I need more. When looking updating data in array code (below), I found something interesting. If 'pData' does not point 'pDataPtr', 'pData' will be freed first.
#define UPDATE_DATA(ht, p, pData, nDataSize) \
if (nDataSize == sizeof(void*)) { \
if ((p)->pData != &(p)->pDataPtr) { \
pefree_rel((p)->pData, (ht)->persistent); \
} \
memcpy(&(p)->pDataPtr, pData, sizeof(void *)); \
(p)->pData = &(p)->pDataPtr; \
}
If I set 'pData' in fake Bucket to the address of $_POST['a'] (zval struct). It will be freed. Then, I trick PHP to allocate craft string on that memory area. Finally, I can alter zval struct of $_POST['a'] to point to any address and the PHP code will echo the data in that memory area to me. But after altering the zval struct, the PHP will crash when clearing all variables. That's why I add the PHP code for flushing the output.
I can trick PHP to allocate on just freed memory area because in php_sapi_filter(), the estrndup() is called (at line 479) almost immediately after called php_register_variable_ex() (at line 461). With the Zend Memory Management Cache that I described a little in this post, all I need to do is using the trigger input value to be fake zval struct.
I still cannot find the way to know the exact address of $_POST['a']. I do brute forcing again. I know the heap address. It must be near. I test the result from dumping my fake HashTable. My method for brute forcing $_POST['a'] address is not reliable. Especially when PHP-FPM has many children.
Here is my output (code again php_rce_poc.py)
$ python php_rce_poc.py Trying addr: b6c00018 Trying addr: b6c40018 Trying addr: b6c80018 Trying addr: b6cc0018 Trying addr: b6d00018 Trying addr: b6d40018 Trying addr: b6d80018 Trying addr: b6dc0018 Fake addr: b6dc0018 Heap addr: 08fe3180 Bruteforcing param_addr... param addr: 08fe30a0 dumping memory at 0x08048000 ⌂ELF☺☺☺ ☻ ♥ ☺ 04
After able to dump any memory address + controlling EIP/RIP, it is highly possible to do code execution. That's it for me.
Update (5 Feb 2012): a little change on my code (php_rce_poc2.py).
- Increase the search fake chunk range to make it work on apache2/mod_php5
- Dump data at least 8192 bytes. So no need the PHP code for flushing output buffer.
