從PHP內核來看CVE-2016-712 - 網安 - 專業的網絡安全產業、社區、知識平臺

STATEMENT

聲明

由于傳播、利用此文所提供的信息而造成的任何直接或者間接的后果及損失，均由使用者本人負責，雷神眾測及文章作者不為此承擔任何責任。

前言

本文使用的是php5.6.10版本源碼，我們主要來看看該版本下繞過wakup魔術方法這個CVE-2016-7124漏洞，用以記錄前段時間的分析。

serialize分析

先寫一個小demo，不含__sleep()函數的：

<?phpclass 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魔術方法的：

<?phpclass 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分析

<?phpclass 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：

<?phpclass 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的邏輯錯誤導致的。