关于昨日爆出的 Nginx + PHP CGI 漏洞的一点点补充

我第一次看到这个漏洞是在 Laruence 的博客。看完之后,我赶紧评估了一下我们正在开发的产品出现这个漏洞的可能性。还不错,在我们当前架构下,这个漏洞被成功利用的可能性为 0 …… 结果,今天在大嘴巴 cnbeta 看到了这篇很标题党的新闻《80后发现nginx 0day漏洞,上传图片可入侵100万服务器》。然后引用的出处是这里。 好了,我认为我提供的背景资料足够详细了。现在说说为什么我们的产品不会出现这个被利用的可能吧。 其实很简单,将资源文件和 php 脚本文件放在不同的域名下面。然后将资源文件(含产品自身的和用户贡献的)的访问限于只作文件传输,不作任何的脚本解析。 例如 PHP 脚本执行的主机名是 www.mikespook.com。而上传文件和图像、js、css 等放在 static.mikespook.com 主机名下。 其实,就是这么简单的一个隔离措施,就避免了出现这种上传并解析的漏洞。 即使想用同一个域名,通过对 nginx 的配置禁止资源文件目录下的文件被当作脚本解析也是很容易的。 这个故事教育我们:细节是基石,架构是王道!!! 另,根据来自高春辉的可靠消息,手机之家也不存在此问题……

mb_ereg(i)_replace() 执行任意代码的漏洞

这个漏洞说大也大,说小也小。大是因为真得可以通过注入的方式让漏洞代码执行任意代码。小是因为产生漏洞的环境还是比较苛刻的。 来源于此:http://milw0rm.com/exploits/8641 当最后一个参数设置为“e”,也就是将替换的内容作为 PHP 代码执行的时候,漏洞就产生了。 例如: function hi80vul() {} $str = ‘\’, phpinfo(), \”; mb_ereg_replace(‘^(.*)$’, ‘hi80vul(\’\1\’)’, $str, ‘e’); 又例如: function hi80vul() {} $str = ‘\’, var_dump(get_loaded_extensions()), \”; mb_ereg_replace(‘^(.*)$’, ‘hi80vul(\’\1\’)’, $str, ‘e’); 如果有在代码中使用过 mb_ereg_replace 和 mb_eregi_replace,以及参数“e”,那就赶紧检查一下是否有这样的安全隐患吧。