php escapeshellcmd多字节编码漏洞解析及延伸
互联网 发布时间:2008-10-08 20:02:02 作者:佚名
我要评论
漏洞公告在http://www.sektioneins.de/advisories/SE-2008-03.txt
PHP 5 <= 5.2.5
PHP 4 <= 4.4.8
一些允许如GBK,EUC-KR, SJIS等宽字节字符集的系统都可能受此影响,影响还是非常大的,国内的虚拟主机应该是通杀的,在测试完这个漏洞之
漏洞公告在http://www.sektioneins.de/advisories/SE-2008-03.txt
PHP 5 <= 5.2.5
PHP 4 <= 4.4.8
一些允许如GBK,EUC-KR, SJIS等宽字节字符集的系统都可能受此影响,影响还是非常大的,国内的虚拟主机应该是通杀的,在测试完这个漏洞之后,发现还是十分有意思的,以前也有过对这种类型安全漏洞的研究,于是就把相关的漏洞解释和一些自己的想法都写出来,也希望国内的一些有漏洞的平台能迅速做出响应,修补漏洞。
这个漏洞出在php的用来转义命令行字符串的函数上,这些函数底层是用的php_escape_shell_cmd这个函数的,我们先来看看他的处理过程:
/* {{{ php_escape_shell_cmd
Escape all chars that could possibly be used to
break out of a shell command
This function emalloc’s a string and returns the pointer.
Remember to efree it when done with it.
*NOT* safe for binary strings
*/
char *php_escape_shell_cmd(char *str) {
register int x, y, l;
char *cmd;
char *p = NULL;
l = strlen(str);
cmd = safe_emalloc(2, l, 1);
for (x = 0, y = 0; x < l; x ) {
switch (str[x]) {
case ’"’:
case ’\’’:
#ifndef PHP_WIN32
if (!p && (p = memchr(str x 1, str[x], l - x - 1))) {
/* noop */
} else if (p && *p == str[x]) {
p = NULL;
} else {
cmd[y ] = ’\\’;
}
cmd[y ] = str[x];
break;
#endif
case ’#’: /* This is character-set independent */
case ’&’:
case ’;’:
case ’`’:
case ’|’:
case ’*’:
case ’?’:
case ’~’:
case ’<’:
case ’>’:
case ’^’:
case ’(’:
case ’)’:
case ’[’:
case ’]’:
case ’{’:
case ’}’:
case ’$’:
case ’\\’:
case ’\x0A’: /* excluding these two */
case ’\xFF’:
#ifdef PHP_WIN32
/* since Windows does not allow us to escape these chars, just remove them */
case ’%’:
cmd[y ] = ’ ’;
break;
#endif
cmd[y ] = ’\\’;
/* fall-through */
default:
cmd[y ] = str[x];
}
}
cmd[y] = ’\0’;
return cmd;
}
/* }}} */
可以看到,php通过将",’,#,&,;.....等等在shell命令行里有特殊意义的字符都通过在前面加上\变成\".\’,\#,\&,\;......来进行转义,使得用户的输入被过滤,来避免产生command injection漏洞。在php看来,只要过滤了这些字符,送入到system等函数中时,参数就会是安全的,php手册中给出的利用例子如下:
<?php
$e = escapeshellcmd($userinput);
// here we don’t care if $e has spaces
system("echo $e");
$f = escapeshellcmd($filename);
// and here we do, so we use quotes
system("touch \"/tmp/$f\"; ls -l \"/tmp/$f"");
?>
很明显,如果没有经过escapeshellcmd的处理,用户输入hello;id的话,最后system执行的会是:
echo hello;id
;在shell里是分割命令的作用,这样不仅仅会echo hello,还会执行id这个命令,导致命令注入漏洞。用escapeshellcmd处理之后命令变成:
echo hello\;id
这样执行的命令就只会是echo,其他的都变成echo的参数,很安全。
事实上是这样么?php在处理完参数送入system之后它就什么都不管了,后面的工作实际上都是由linux来完成的,那么linux在处理这些参数的时候是怎么样的呢?linux在执行命令的时候会有一些的表示工作环境的环境变量,譬如PWD代表当前的工作环境,UID代表了你的身份,BASH代表命令解释器等等......而在linux系统执行命令的时候,还有一个非常重要的参数,LANG,这个参数决定了linux shell如何处理你的输入,这样就可以当你输入一些中文字符的时候,linux能认识他,不至于出现人与系统之间出现理解上的错误。默认情况下,linux的LANG是en_US.UTF-8,UTF-8是一个很安全的字符集,其系列中包含有对自身的校验,所以不会出现错误,会工作良好。一些系统支持多字节字符集如GBK的时候,这也正是国内的多数情况,你可以设置LANG=zh_CN.GBK,这样你的输入都会被当作GBK编码处理,而GBK是双字节的,合法的GBK编码会被认为是一个字符。
大家可以看到,在php的处理过程中,它是单字节处理的,它只把输入当作一个字节流,而在linux设置了GBK字符集的时候,它的处理是双字节的,大家的理解很明显地不一致。我们查下GBK的字符集范围为8140-FEFE,首字节在 81-FE 之间,尾字节在 40-FE 之间,而一个非常重要的字符\的编码为5c,在GBK的尾字节范围之内,这样我们考虑一个特殊的输入:
0xbf;id
或 0xbf’id
经过php的escapeshellcmd单字节转码之后将会是
0xbf5c;id
0xbf5c’id
注意0xbf5c是一个合法的GBK编码,那么在linux执行的时候,会认为输入是
[0xbfbc];id
很好,后面的id将会被执行。可以做个简单的实验,如下:
[loveshell@Loveshell tmp]$Content$nbsp;echo 縗
>
?
[loveshell@Loveshell tmp]$Content$nbsp;set|grep -i lang
LANG=zh_CN.GB2312
LANGVAR=en_US.UTF-8
[loveshell@Loveshell tmp]$Content$nbsp;export LANG=zh_CN.GBK
[loveshell@Loveshell tmp]$Content$nbsp;echo 縗
縗
[loveshell@Loveshell tmp]$Content$nbsp;set|grep -i lang
LANG=zh_CN.GBK
LANGVAR=en_US.UTF-8
[loveshell@Loveshell tmp]$Content$nbsp;
其中縗的编码为0xbf5c,可以看到在不设置LANG为GBK的时候縗是一个非法的gb2312编码,所以会被认为是两个字符,所以其中含有的0x5c起作用,被认为命令没结束。然后我们设置编码为GBK,縗就会被认为是一个字符来echo了。
那我们如何来证明php的漏洞呢,拿
作为例子,正常情况下上面的代码工作很好,我们提交
exp.php?c=loveshell
PHP 5 <= 5.2.5
PHP 4 <= 4.4.8
一些允许如GBK,EUC-KR, SJIS等宽字节字符集的系统都可能受此影响,影响还是非常大的,国内的虚拟主机应该是通杀的,在测试完这个漏洞之后,发现还是十分有意思的,以前也有过对这种类型安全漏洞的研究,于是就把相关的漏洞解释和一些自己的想法都写出来,也希望国内的一些有漏洞的平台能迅速做出响应,修补漏洞。
这个漏洞出在php的用来转义命令行字符串的函数上,这些函数底层是用的php_escape_shell_cmd这个函数的,我们先来看看他的处理过程:
/* {{{ php_escape_shell_cmd
Escape all chars that could possibly be used to
break out of a shell command
This function emalloc’s a string and returns the pointer.
Remember to efree it when done with it.
*NOT* safe for binary strings
*/
char *php_escape_shell_cmd(char *str) {
register int x, y, l;
char *cmd;
char *p = NULL;
l = strlen(str);
cmd = safe_emalloc(2, l, 1);
for (x = 0, y = 0; x < l; x ) {
switch (str[x]) {
case ’"’:
case ’\’’:
#ifndef PHP_WIN32
if (!p && (p = memchr(str x 1, str[x], l - x - 1))) {
/* noop */
} else if (p && *p == str[x]) {
p = NULL;
} else {
cmd[y ] = ’\\’;
}
cmd[y ] = str[x];
break;
#endif
case ’#’: /* This is character-set independent */
case ’&’:
case ’;’:
case ’`’:
case ’|’:
case ’*’:
case ’?’:
case ’~’:
case ’<’:
case ’>’:
case ’^’:
case ’(’:
case ’)’:
case ’[’:
case ’]’:
case ’{’:
case ’}’:
case ’$’:
case ’\\’:
case ’\x0A’: /* excluding these two */
case ’\xFF’:
#ifdef PHP_WIN32
/* since Windows does not allow us to escape these chars, just remove them */
case ’%’:
cmd[y ] = ’ ’;
break;
#endif
cmd[y ] = ’\\’;
/* fall-through */
default:
cmd[y ] = str[x];
}
}
cmd[y] = ’\0’;
return cmd;
}
/* }}} */
可以看到,php通过将",’,#,&,;.....等等在shell命令行里有特殊意义的字符都通过在前面加上\变成\".\’,\#,\&,\;......来进行转义,使得用户的输入被过滤,来避免产生command injection漏洞。在php看来,只要过滤了这些字符,送入到system等函数中时,参数就会是安全的,php手册中给出的利用例子如下:
<?php
$e = escapeshellcmd($userinput);
// here we don’t care if $e has spaces
system("echo $e");
$f = escapeshellcmd($filename);
// and here we do, so we use quotes
system("touch \"/tmp/$f\"; ls -l \"/tmp/$f"");
?>
很明显,如果没有经过escapeshellcmd的处理,用户输入hello;id的话,最后system执行的会是:
echo hello;id
;在shell里是分割命令的作用,这样不仅仅会echo hello,还会执行id这个命令,导致命令注入漏洞。用escapeshellcmd处理之后命令变成:
echo hello\;id
这样执行的命令就只会是echo,其他的都变成echo的参数,很安全。
事实上是这样么?php在处理完参数送入system之后它就什么都不管了,后面的工作实际上都是由linux来完成的,那么linux在处理这些参数的时候是怎么样的呢?linux在执行命令的时候会有一些的表示工作环境的环境变量,譬如PWD代表当前的工作环境,UID代表了你的身份,BASH代表命令解释器等等......而在linux系统执行命令的时候,还有一个非常重要的参数,LANG,这个参数决定了linux shell如何处理你的输入,这样就可以当你输入一些中文字符的时候,linux能认识他,不至于出现人与系统之间出现理解上的错误。默认情况下,linux的LANG是en_US.UTF-8,UTF-8是一个很安全的字符集,其系列中包含有对自身的校验,所以不会出现错误,会工作良好。一些系统支持多字节字符集如GBK的时候,这也正是国内的多数情况,你可以设置LANG=zh_CN.GBK,这样你的输入都会被当作GBK编码处理,而GBK是双字节的,合法的GBK编码会被认为是一个字符。
大家可以看到,在php的处理过程中,它是单字节处理的,它只把输入当作一个字节流,而在linux设置了GBK字符集的时候,它的处理是双字节的,大家的理解很明显地不一致。我们查下GBK的字符集范围为8140-FEFE,首字节在 81-FE 之间,尾字节在 40-FE 之间,而一个非常重要的字符\的编码为5c,在GBK的尾字节范围之内,这样我们考虑一个特殊的输入:
0xbf;id
或 0xbf’id
经过php的escapeshellcmd单字节转码之后将会是
0xbf5c;id
0xbf5c’id
注意0xbf5c是一个合法的GBK编码,那么在linux执行的时候,会认为输入是
[0xbfbc];id
很好,后面的id将会被执行。可以做个简单的实验,如下:
[loveshell@Loveshell tmp]$Content$nbsp;echo 縗
>
?
[loveshell@Loveshell tmp]$Content$nbsp;set|grep -i lang
LANG=zh_CN.GB2312
LANGVAR=en_US.UTF-8
[loveshell@Loveshell tmp]$Content$nbsp;export LANG=zh_CN.GBK
[loveshell@Loveshell tmp]$Content$nbsp;echo 縗
縗
[loveshell@Loveshell tmp]$Content$nbsp;set|grep -i lang
LANG=zh_CN.GBK
LANGVAR=en_US.UTF-8
[loveshell@Loveshell tmp]$Content$nbsp;
其中縗的编码为0xbf5c,可以看到在不设置LANG为GBK的时候縗是一个非法的gb2312编码,所以会被认为是两个字符,所以其中含有的0x5c起作用,被认为命令没结束。然后我们设置编码为GBK,縗就会被认为是一个字符来echo了。
那我们如何来证明php的漏洞呢,拿
作为例子,正常情况下上面的代码工作很好,我们提交
exp.php?c=loveshell
相关文章

2019最新RDP远程桌面漏洞官方补丁(针对win2003、win2008)
Windows系列服务器于2019年5月15号,被爆出高危漏洞,windows2003、windows2008、windows2008 R2、windows xp系统都会遭到攻击,该服务器漏洞利用方式是通过远程桌面端口332021-07-25
宝塔面板 phpmyadmin 未授权访问漏洞 BUG ip:888/pma的问题分析
这篇文章主要介绍了宝塔面板 phpmyadmin 未授权访问漏洞 BUG ip:888/pma,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下2020-08-24
CPU幽灵和熔断漏洞是什么?Intel为大家简单易懂的科普了一番
不久前让整全行业紧张、全球用户恐慌的Spectre幽灵、Meltdown熔断两大漏洞事件刚刚告一段落了,那么这两个漏洞到底是什么?可能还有很多人不是很清楚,想了解的朋友跟着小2018-03-21
2017年5月12日,WannaCry蠕虫通过MS17-010漏洞在全球范围大爆发,感染了大量的计算机,该蠕虫感染计算机后会向计算机中植入敲诈者病毒,导致电脑大量文件被加密,本文对其2017-05-17- 大部分的用户可能不要了解文件上传漏洞,下面小编就为大家具体的讲解什么事文件上传漏洞以及文件上传漏洞的几种方式2016-11-02
- 漏洞检测工具用语有高危漏洞,中危漏洞,低危漏洞以及漏洞的危害介绍,本文介绍的非常详细,具有参考解决价值,感兴趣的朋友一起看看吧2016-10-11
- 漏洞无处不在,它是在硬件、软件、协议的具体实现或系统安全策略上存在的缺陷,从而可以使攻击者能够在未授权的情况下访问或破坏系统2016-09-29
手把手教你如何构造Office漏洞POC(以CVE-2012-0158为例)
近年来APT追踪盛行,最常见的就是各种以钓鱼开始的攻击,不仅仅有网站挂马式钓鱼,也有鱼叉式邮件钓鱼,下面小编就为大家介绍office漏洞CVE-2012-0158,一起来看看吧2016-09-28- SSL(安全套接字层)逐渐被大家所重视,但是最不能忽视的也是SSL得漏洞,随着SSL技术的发展,新的漏洞也就出现了,下面小编就为大家介绍简单七步教你如何解决关键SSL安全问题2016-09-23
- 在爬虫开发中,大家可以很轻易地 bypass 所谓的 UA 限制,甚至用 scrapy 框架轻易实现按照深度进行爬行。但是实际上,这些并不够。关于爬虫的基础知识比如数据处理与数据存2016-09-12






最新评论