[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 
___FCKpd___0
request) {
	foreach($_request as 
___FCKpd___0
key => 
___FCKpd___0
value) {
		
___FCKpd___0
key{0} != '_' && $_key = daddslashes(
___FCKpd___0
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-