[PCH-009]Security risk of php string offset

by ryat_at_www.80vul.com

一、前言[關于PCH]

"PCH"及"Php Codz Hacking"是80vul在2009年4月推出的一個項目，主要是在php源代碼的基
礎分析和探討一些可以給php應用安全帶來影響的'特性'或者'漏洞'。這個項目最早起源于
webzine 0x3里的《高級PHP應用程序漏洞審核技術》[1]:

* 分析php源代碼，發現新的漏洞函數“特性”或者漏洞。（在上一節里介紹的那些“漏洞審
計策略”里，都沒有php源代碼的分析，如果你要進一步找到新的字典，可以在php源代碼的
基礎上分析下成因，然后根據這個成因來分析尋找新的漏洞函數“特性”或者漏洞。）

而本文就是PCH的一篇，在php的代碼基礎上分析PHP字符串offset一個可以給PHP應用程序帶
來安全風險的小"特性"...


二、PHP String Offset

先來看看手冊中關于字符串offset取值特性的一段描述[詳見[2]]:

String access and modification by character

Characters within strings may be accessed and modified by specifying the 
zero-based offset of the desired character after the string using square array 
brackets, as in $str[42]. Think of a string as an array of characters for this 
purpose. The functions substr() and substr_replace() can be used when you want 
to extract or replace more than 1 character.

    Note: Strings may also be accessed using braces, as in $str{42}, for the 
same purpose. 
    

通過這個特性可以很方便的對字符串進行修改或者取值等操作,比如下面的代碼:

$xigr = 'ryat';
echo $xigr[0];
// echo r

再看看這段代碼:

echo $xigr['hi'];
// echo r

為什么對于字符串$xigr來說,$xigr[0]和$xigr['hi']取得值是一樣的呢?讓我們來看看PHP部
分源碼...

三、PHP源碼分析:

// zend_execute.c
static void zend_fetch_dimension_address(temp_variable *result, zval **container_ptr, zval *dim, int dim_is_tmp_var, int type TSRMLS_DC)
{
	zval *container = *container_ptr;
	zval **retval;

	switch (Z_TYPE_P(container)) {
...
		case IS_STRING: {
				zval tmp;

				if (type != BP_VAR_UNSET && Z_STRLEN_P(container)==0) {
					goto convert_to_array;
				}
				if (dim == NULL) {
					zend_error_noreturn(E_ERROR, "[] operator not supported for strings");
				}

				if (Z_TYPE_P(dim) != IS_LONG) {
					switch(Z_TYPE_P(dim)) {
						/* case IS_LONG: */
						case IS_STRING:
						case IS_DOUBLE:
						case IS_NULL:
						case IS_BOOL:
							/* do nothing */
							break;
						default:
							zend_error(E_WARNING, "Illegal offset type");
							break;
					}

					tmp = *dim;
					zval_copy_ctor(&tmp);
					convert_to_long(&tmp);
					dim = &tmp;
...

上面的代碼片段可以看出,對于$xigr['hi']這種形式的字符串,在offset取值時鍵值會被轉換
為整形,也就是等同于$xigr[0]這種形式:)

四、帶來的應用安全風險

雖然這是一個很方便的特性,但是如果開發者對這個特性沒有充分的認識或者忽視的時候，就
可以給應用程序帶來災難性的安全漏洞。這個主要體現開發者在處理數組變量名時沒有指定
變量類型，當這個數組變量被惡意提交字符類型來取值，導致的一些安全風險。

1、繞過某些條件判斷

如在phpspy2006的代碼在判斷登錄時使用了如下條件判斷：


$admin['check'] = "1";
$admin['pass']  = "angel";
 ......
if($admin['check'] == "1") {
....
}

$admin沒有被初始定義為數組類型，那么當我們用字符串提交時phpsyp.php?admin=1xxx時，
php會取字符串1xxx的第一位，成功繞過if的條件判斷。

[PS:此漏洞是由80vul的saiy發現的，thx]


2、"魔術引號帶來的新的安全問題"

在《高級PHP應用程序漏洞審核技術》[1]一文里的"魔術引號帶來的新的安全問題"一節里，有
提到通過提取魔術引號產生的“\”字符帶來的安全問題，同樣這個問題在這里又一次完美體
現，如下面的代碼片段:

// foo.php?xigr='ryat
function daddslashes($string, $force = 0) {
	!defined('MAGIC_QUOTES_GPC') && define('MAGIC_QUOTES_GPC', get_magic_quotes_gpc());
	if(!MAGIC_QUOTES_GPC || $force) {
		if(is_array($string)) {
			foreach($string as $key => $val) {
				$string[$key] = daddslashes($val, $force);
			}
		} else {
			$string = addslashes($string);
		}
	}
	return $string;
}
...
foreach(array('_COOKIE', '_POST', '_GET') as $_request) {
	foreach($$_request as $_key => $_value) {
		$_key{0} != '_' && $$_key = daddslashes($_value);
	}
}

echo $xigr['hi'];
// echo \

上面的代碼原本期望得到一個經過daddslashes()安全處理后的數組變量$xigr['hi'],但是沒
有對變量$xigr做嚴格的類型規定，當我們提交一個字符串變量$xigr='ryat,經過上面的處理
變為\'ryat,到最后$xigr['hi']就會輸出\,如果這個變量引入到SQL語句,那么就會引起嚴重
的安全問題了,再來看下面的代碼片段:

...
if($xigr) {
	foreach($xigr as $k => $v) {
		$uids[] = $v['uid'];
	}
	$query = $db->query("SELECT uid FROM users WHERE uid IN ('".implode("','", $uids)."')");

利用上面提到的思路,通過提交foo.php?xigr[]='&xigr[][uid]=evilcode這樣的構造形式可
以很容易的突破GPC或類似的安全處理,形成SQL注射漏洞:D


五、后話

上面的例子再一次說明努力挖掘PHP本身的特性或者漏洞才是PHP應用安全的主要出路。另外
還有一句話送給各位看官“蟲子永遠屬于那些有想法勤勞的小鳥”。

六、參考
[1]http://code.google.com/p/pasc2at/wiki/SimplifiedChinese
[2]:http://php.net/manual/en/language.types.string.php

-EOF-