关于phpMyAdmin 3.x漏洞
先看看老外发布的漏洞公告《phpmyadmin-3x-multiple-remote-code.html" target="_blank">phpMyAdmin 3.x Multiple Remote Code Executions》,文章里总共提到了4个vulnerability。但是这些漏洞的关键是第一个漏洞,也就是通过parse_str实现覆盖$_SESSION变量的漏洞,而后面的3个都是,覆盖$_SESSION后的利用。这里赞一下漏洞发现者和phpmyadmin官方人员的意识,因为官方也承认了其他的3个漏洞并且给出了对应的修补方式,详细见:PMASA-2011-8/7/6/5 这个也就是我多次在blog和文章里提到的“二次攻击漏洞”及修补原则:“一切进入函数的变量是有害的”、“进入函数前那刹那的防御才是王道”...
再来具体看看漏洞原因及利用:
File: libraries/auth/swekey/swekey.auth.lib.php
if (strstr($_SERVER['QUERY_STRING'],'session_to_unset') != false)
{
parse_str($_SERVER['QUERY_STRING']);
session_write_close();
session_id($session_to_unset);
session_start();
$_SESSION = array();
session_write_close();
session_destroy();
exit;
}
对于parse_str($_SERVER['QUERY_STRING']);导致的变量覆盖的问题,大家应该不会陌生,在《高级PHP应用程序漏洞审核技术》就有提到。至于通过parse_str覆盖$_SESSION后的问题,由于当时我对php处理$_SESSION的问题的认识一直比较模糊,并且由于时间问题对phpmyadmin的这个漏洞提交流程确实全面的认识,就凭着以往的一些经验,在设置php.ini里的session.auto_start = 1,然后就成功触发了该漏洞,这个也就是wofeiwo公布的那个exploit里要求“session.auto_start = 1 in php.ini configuration.”的原因。不过对于为什么要求session.auto_start的原因,我还是不清楚,后来有时间时候,经过wofeiwo的指点才搞清楚:
<?php
//sess_1.php
$_SESSION['abcde'] = "aaaa";
session_start();
var_dump($_SESSION);
?>
<?php
//sess_2.php
session_start();
$_SESSION['abcde'] = "aaaa";
session_start();
var_dump($_SESSION);
?>
当session.auto_start =1是php自身自动实现了一个session_start();所以直接提交sess_1.php时必须要求session.auto_start = 1,$_SESSION['abcde'] = "aaaa";才可以注册成功。我们回到phpmyadmin那么只要我们,在require libraries/auth/swekey/swekey.auth.lib.php这个文件之前有session_start();就行,那么我们在\libraries\session.inc.php 里找到了满足要求的session_start():
if (! isset($_COOKIE[$session_name])) {
// on first start of session we check for errors
// f.e. session dir cannot be accessed - session file not created
$orig_error_count = $GLOBALS['error_handler']->countErrors();
$r = session_start();
if ($r !== true || $orig_error_count != $GLOBALS['error_handler']->countErrors()) {
setcookie($session_name, '', 1);
PMA_fatalError('strSessionStartupErrorGeneral');
}
unset($orig_error_count);
} else {
@session_start(); //这里
}
那么我们通过主页提交就可以了,具体的包含文件流程就不分析了。这时候作者也给出了他的一个exp:《phpMyAdmin 3.x Swekey Remote Code Injection Exploit》,但是经过测试你会发现这个exp的成功率不高及时满足config目录的条件下,这个是因为作者的exp里的playload受到魔术引号导致的,于是就有了oldjun的exp.
以上的exp都是基于漏洞公告里的“The second vulnerability”的利用,后来作者又给出了“The third vulnerability”的exp:http://ha.xxor.se/2011/07/phpmyadmin-3x-pregreplace-rce-poc.html对于利用来讲,这个exp先天不足本身受魔术引号的影响!