STATEMENT
声明
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，雷神众测及文章作者不为此承担任何责任。
雷神众测拥有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经雷神众测允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。
前言
本文使用的是php5.6.10版本源码，我们主要来看看该版本下绕过wakup魔术方法这个CVE-2016-7124漏洞，用以记录前段时间的分析。
serialize分析
先写一个小demo，不含__sleep()函数的：
class serialize_test{public $a = 'nekoc';public $b = 123456;function show(){echo 123;}}$obj = new serialize_test();echo serialize($obj);
接下来在/php-5.6.10/ext/standard/var.c下面，找到PHP_FUNCTION(serialize)，这里是定义serialize的函数，在其中下一个断点，接下来开始调试，让其直接跳到serialize函数这里。
开始调试后发现，php经过一系列的处理后，进入到php_var_serialize函数对序列化进行处理：
接下来继续跟进php_var_serialize_intern方法，只列举重要部分，可以看到，该处根据struc的值来判断进入到哪个case循环，由于struc的值为5，根据定义：
判断进入IS_OBJECT的case下进行处理：
在该case中的处理如下图：
由于在demo中没写__sleep()函数，所以在处理__sleep()函数的位置被跳过，所以在IS_OBJECT中没有一处函数被执行，而且case中不存在跳出循环的语句，所以代码继续向下走，来到IS_ARRAY中进行处理：
经过一系列处理后，代码来到php_var_serialize_intern函数递归解析哈希数组，最后将序列化后的代码存到buf中，至此，序列化过程结束。
接下来，我们在demo中添加一段__sleep魔术函数，来看看PHP是如何处理__sleep魔术方法的：
class serialize_test{public $a = 'nekoc';public $b = 123456;function show(){echo 123;}function __sleep(){$this->show();return ['1','2','3'];}}$obj = new serialize_test();echo serialize($obj);
进入到处理__sleep()方法后，跟进到call_user_function_ex方法中：
在此方法中，对传入的参数进行赋值给fci后，将fci交给zend_call_function方法处理，而且，此时的fci.function_name就是我们在demo中新增的__sleep方法，接下来，在zend_call_function方法中，PHP会将我们在__sleep中写的操作压进zend_vm引擎中，而后，利用zend_execute方法进行解析，这里就不再过多赘述。
unserialize分析
class serialize_test{public $a = 'nekoc';public $b = 123456;function show(){echo 123;}}$obj = new serialize_test();$ser = serialize($obj);$unser = unserialize($ser);var_dump($unser);
我们在PHP_FUNCTION(serialize)方法下方找到PHP_FUNCTION(unserialize)下断点：
开始调试后，依据流程进入到php_var_unserialize方法，由于序列化后的第一个字母为O，所以在函数中判断为object对象，接下来跳转到处理对象的流程，经历两个处理后，流程来到yy20，首先，会检查当前的类名是否存在：
接下来，利用object_common1方法判断当前剩余的元素个数：
接下来将elements参数交给object_common2方法：
在此方法中我们可以看到，首先使用了process_nested_data判断了一个东西，接下来判断我们自定义的类中是否存在__wakeup方法，有的话就像serialize流程一样使用call_user_function_ex进行调用，我们接下来就重点看process_nested_data这段判断的代码：
在process_nested_data方法中，首先使用了两段php_var_unserialize方法，一个解析了序列化字符串对中名称，另一个解析名称对应的值，至此，反序列化部分基本结束。综上我们可以得出序列化与反序列化的一个流程：
序列化：调用__sleep—>利用zend_vm进行解析—>序列化操作
反序列化：获取反序列化字符串—>根据类型进行反序列化—>检测是否有这个类—>判断元素个数—>解析字符串—>判断是否有wakeup方法—>调用wakeup方法
经过简单了解的源码结构，我们可以看看CVE-2016-7124这个漏洞，由于php5.6.10的代码逻辑问题，导致反序列化时首先被调用的__wakeup方法可以被绕过，下面给出这个漏洞复现的demo：
class test{public $a = 'hello';public function __wakeup(){var_dump("wakeup");}public function __destruct(){var_dump("destruct");}}unserialize('O:4:"test":2:{s:1:"a";s:5:"hello";}');// 执行时绕过了wakeup函数，只输出了destruts，以下几种都可以实现相同的效果unserialize('O:4:"test":2:{s:2:"a";s:5:"hello";}');unserialize('O:4:"test":2:{s:1:"a";s:4:"hello";}');unserialize('O:4:"test":1:{s:1:"a";s:6:"hello";}');
执行以上代码我们发现，在控制台上只会输出destruct，__wakeup方法根本没被调用，这是为什么呢，我们接下来开始调试跟一下代码看看。
在调试的过程中，我们发现，在调用__wakeup方法前有一处使用了process_nested_data进行了判断：
并且该函数的返回值为0，调试时发现流程到这里时直接被返回了，在上面我们知道process_nested_data做了解析字符串名称的操作，我们继续跟进看看到底发生了什么。
在跟进process_nested_data的时候我们发现，其中的while循环被成功的执行了一次，在第二次执行时，当流程进入第一个php_var_unserialize的时候，解析失败了，这就导致直接被返回了0值，跳过了__wakeup的解析过程，而这，正是我们payload中修改的部分，我们将序列化后的字符串中对象属性的个数由原来的1改为了2，导致解析失败，所以才绕过了__wakeup方法的执行，而在demo中给出的其他payload都是修改了要解析成员的字符数，这样也会导致解析失败而跳过__wakeup的执行，而这是php5.6.10的逻辑错误导致的。
征稿通知
知识应该被分享，安全更需携手共进
RECRUITMENT
招聘启事
END
长按识别二维码关注我们
原文始发于微信公众号（雷神众测）：从PHP内核来看CVE-2016-712
