Home > Article > Backend Development > PHP-5.3.9 Remote Arbitrary Code Execution Vulnerability (CVE-2012-0830) Detailed Explanation_PHP Tutorial
Remember the PHP Hash Collisions Ddos vulnerability I mentioned before? At first, the repair plan given by the development team was to report an error (E_ERROR) if it exceeds max_input_vars, which in turn caused PHP to end with an error. Later, In order to solve this problem more lightweight, we improved it and changed it to issue a warning (E_WARNING) if max_input_vars is exceeded, and no longer add to the destination array, but the process continues. Then we released 5.3.9.
This new fix has good intentions, but it brings about a serious problem (fixed in 5.3.10), which was originally discovered by Stefan Esser. Please see the previous (5.3.9) final Fix (php_register_variable_ex):
The code is as follows | Copy code | ||||
|
Note that if you register an array variable at this time (similar to: a[]=2 in GET), and this variable happens to be the max_input_vars-th variable, a warning (1) will be triggered, and everything is normal at this time. .
However, if you still register an array variable at this time, but this variable is already the max_input_vars + 1th variable, then gpc_element_p will become an uninitialized pointer at this time, and because the logic will continue now, that is will go to position (2), causing an uninitialized pointer to be dereferenced. So, Boomb~
So, at this point, we can use this feature to do Ddos on 5.3.9. If the Server has Core Dump enabled, the effect will be very obvious.
However, this problem can also lead to a more serious problem:
Still the above code, there is a loop in the outermost layer. When this loop takes effect, when registering a pair similar to a[b]=2, the loop will be executed twice. The first time a will be inserted. [], insert b into a[] for the second time. Then let us pay attention to (3). If the desired element cannot be found in the destination array, **or the element is not an array**, then It will also directly cause the process to be left to (2), so problems arise.
For a POST string like this (default max_input_vars is 1000):
1=1&1=2&..........&999=1&x="I am a malicious string"&x[0]=
What will happen?
Let me describe it step by step:
1. There is no problem from 1 to 999, they are all inserted normally
2. x is 1000 elements, so a warning is triggered and there is no problem, x is inserted
3. When x[0] is inserted, statement (3) determines that it is not Arrary and enters the if body. However, statement (4) fails at this time, so the process finally flows to (2)
4. At this time, gpc_element_p points to x, which is the string we forged...
Now let’s look at the key data structure, zval:
The code is as follows | Copy code | ||||||||
|
The code is as follows | Copy code |
typedef union _zvalue_value { long lval; /* long value */ double dval; /* double value */ struct { char *val; int len; } str; HashTable *ht; /* hash table value */ zend_object_value obj; } zvalue_value;< li> |
zvalue_value is a union, so the memory of the string area we construct will be treated as a Hashtable structure:
The code is as follows
|
Copy code
|
||||
typedef struct _hashtable { uint nTableSize; |
unsigned char nApplyCount;