还记得我之前说的PHP Hash Collisions Ddos漏洞吧? 最初的时候, 开发组给出的修复方案, 采用的是如果超过max_input_vars, 就报错(E_ERROR), 继而导致PHP出错结束. 而后来, 为了更加轻量级的解决这个问题, 我们又改善了一下, 变成了如果超过max_input_vars, 就发出警告(E_WARNING), 并且不再往目的数组添加, 但是流程继续. 然后我们发布了5.3.9.
 
这个新的修复方法初衷是好的, 但是却带来一个严重的问题(5.3.10中已经修复), 这个问题最初是由Stefan Esser发现的. 请看之前(5.3.9)最终的修复方案(php_register_variable_ex):
 
while (1) {
     if (zend_symtable_find(symtable1, escaped_index, index_len + 1, (void **) &gpc_element_p) == FAILURE
          || Z_TYPE_PP(gpc_element_p) != IS_ARRAY) { //(3)
          if (zend_hash_num_elements(symtable1) <= PG(max_input_vars)) {  // (4)
               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)); // (1)
               }
               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);  // (2)
     goto plain;
}
注意到, 如果此时注册一个数组变量(在GET中类似于: a[]=2), 并且此时这个变量刚好是第max_input_vars个变量的时候, 会触发一个警告(1), 此时一切正常.
 
但是, 如果此时还是注册一个数组变量,但是这个变量已经是第max_input_vars + 1个变量的时候, 那么此时gpc_element_p将成为一个未初始化的指针, 而因为现在逻辑会继续走, 也就会走到(2)号位置, 导致解引用了一个未初始化的指针. 于是, Boomb~
 
那么, 到目前位置, 我们就可以使用这样的特性来对5.3.9做Ddos了. 如果Server开启了Core Dump的话, 这个效果会非常明显.
 
然而, 这个问题还会导致一个更严重的问题:
 
还是上面的代码, 在最外层有一个循环, 这个循环起作用的时刻在注册类似于a[b]=2的pair对的时候, 循环将会执行俩次, 第一次插入a[], 第二次往a[]中插入b. 然后再让我们注意下(3), 如果在目的数组中找不到一个想要的元素, **或者这个元素不为数组**, 则也会直接导致流程留到(2), 于是问题就出现了.
 
对于这样的POST串(默认max_input_vars是1000):
 
 1=1&1=2&..........&999=1&x="我是恶意的string"&x[0]=0
会发生什么事情呢?
 
让我来一步一步描述下:
 
1. 从1到999没什么问题, 都被正常插入
 
2. x是1000个元素, 所以触发警告, 也没有问题, x被插入
 
3. x[0]插入的时候, (3)号语句判断发现不是Arrary于是进入if体, 但是此时(4)号语句失败, 于是流程最终流到了(2)
 
4. 此时, gpc_element_p指向x, 也就是那个我们伪造的字符串….
 
现在让我们看看关键的数据结构, zval:
 
struct _zval_struct {
    /* Variable information */
    zvalue_value value;     /* value */
    zend_uint refcount__gc;
    zend_uchar type;    /* active type */
    zend_uchar is_ref__gc;
};
然后看zvalue_value:
 
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;
zvalue_value是一个联合体, 于是我们构造的字符串区域的内存, 就会被当做一个Hashtable结构体:
 
typedef struct _hashtable {
    uint nTableSize;
    uint nTableMask;
    uint nNumOfElements;
    ulong nNextFreeElement;
    Bucket *pInternalPointer;   /* Used for element traversal */
    Bucket *pListHead;
    Bucket *pListTail;
    Bucket **arBuckets;
    dtor_func_t pDestructor;  //注意这个
    zend_bool persistent;
    unsigned char nApplyCount;
    zend_bool bApplyProtection;
#if ZEND_DEBUG
    int inconsistent;
#endif
} HashTable;
在Hashtable结构体中, 有一个pDestructor, 这个指针指向一个函数, 当这个Hashtable中有元素要被清除的时候, 就会调用它…
 
也就是说, 你可以随心所欲的设置一个地址(pDestructor), 然后让PHP去调用它(诱使一个元素被删除).
 
但是, 到目前位置, 因为我们的大多数操作系统都有ASLR+NX保护, 所以这个只是理论上可以执行任意代码, 但实际上到目前为止还不能实际利用这个漏洞.
 
最后, 我之前为5.2提供的Patch, 因为采用的是触发E_ERROR, 所以不存在这个漏洞, 大家已经使用了我之前Patch的同学可以放心. 也谢谢Wingary同学在我了解这个漏洞过程中给予的帮助
 
最最后: 原理我介绍完了, 对于POC的介绍或者讨论, 就超出我写此文的意图了. 我就不再介绍了, 有兴趣的同学可以自己寻找.
 
参考:
http://thexploit.com/sec/critical-php-remote-vulnerability-introduced-in-fix-for-php-hashtable-collision-dos/
http://auntitled.blogspot.com/2012/02/mini-poc-for-php-rce-cve-2012-0830.html