SAE云服务安全沙箱绕过4(绕过文件权限防御)

by 空虚浪子心 http://www.inbreak.net 微博:http://t.qq.com/javasecurity
摘要

谢各位捧场,已经打到第四关了。经过几次交流,发现SAE的童鞋对安全很重视,而且持“欢迎来搞”的态度,对这样的态度,给予肯定,有了这样的态度,作者才有了继续下去的欲望,我们都相信SAE最终会变得越来越安全。

正文

前文《SAE云服务安全沙箱绕过3(绕过命令执行防御)》(http://www.inbreak.net/archives/426),作者利用了SAE仅仅限制EXEC命令,没有限制其他函数的漏洞,打破了整个沙盒的防御,最后给出的建议中,作者也提到了对沙盒的防御方式。SAE接受了常规的沙盒安全方案,不再局限于限制某个函数等策略。现在到处都是限制,这对于作者来说真是艰难困苦的开始,感觉SAE对于沙盒的安全限制,已经比google还要BT了,甚至有些不照顾JAVA框架了,无论如何,作者继续绕了下去。

环境探测
首先看看常规的,危险的几个函数:

crackClassLoader

还是前几篇文章专用的代码,所以本文就不再次贴出来了,直接看结果:

已经限制了createClassLoader,这样我们自定义的classLoader已经无效,这意味着,不能再走定义一个自定义权限的类,这个流程了。

连接socket测试

http://2.javasandboxtest.sinaapp.com/socket.jsp?host=www.inbreak.net&port=80&page=/

不允许socket连接,不允许XXX,不允许XXX。。。

这样绕,不是办法,都被干掉了。这时候,我们需要一种打破常规沙盒绕过的手段。

读文件测试

作者发现了一个非常有趣的情况,SAE的JAVA环境中,有个Class,叫做”com.sina.sae.security.SaeSecurity”,这个Class,像是做验证的,里面有方法“checkRead”。如果知道这个方法的验证逻辑,并且刚好开发人员实现这个方法时,出现了逻辑漏洞,才可能出现bypass。但是在这样的条件下,拿到SAE的源码,非常难,只能可以从侧面探测。

作者想到,如果让这个类,刚好在权限验证时,起效果,并且在java远程的沙盒之前run起来,最简单的架构,是让它直接继承Java.lang.SecurityManager,这个东西是java原生提供的功能,默认会根据java的policy文件中设置的权限白名单,做各种认证。一个Class继承了SecurityManager,就是所谓的自定义SecurityManager,SAE和google都使用了自定义SecurityManager。

查看这个Class的文档说明,里面有很多权限验证的方法,这些验证方法,都可以由开发人员自行实现,覆盖java原生的验证逻辑。


图中有很多验证方法,都可以由开发人员自己实现的验证方法覆盖,一旦SAE的开发人员覆盖了这些方法,比如命令执行,那么在真正java做命令执行前,会验证权限,就使用SAE开发人员写的方法,而不是JAVA原生的验证。

正常JAVA沙盒错误的信息,应该和SAE自己实现的安全认证没有关系,理论上java自己的沙盒,已经具备了文件读取等认证。但是按照前面图中所示的异常信息,作者推测,是SAE的开发人员替代了JAVA原生安全认证。从这里也看出,SAE野心不小,有替换JAVA语言本身安全沙盒的趋势,但是JAVA本身的代码,是经过很多年风吹雨打的,各种bypass都出现过,SAE新写的代码,想达到这个标准,还是比较难的。

下面可以从各种角度,测试SAE自己实现沙盒代码的安全性,checkRead方法,看名字就是验证文件读取权限的。而用户自己上传的文件,必然是可以读取的,否则沙盒的限制,就太BT了。

作者上传了一个文件,然后读取,获取文件路径的方式,见之前作者写的文章《SAE云服务安全沙箱绕过3(绕过命令执行防御)》(http://www.inbreak.net/archives/426)。

这是可以读的,这说明路径:

/data1/jetty_work/84/javasandboxtest/jetty-0.0.0.0-10168-javasandboxtest.war-_3_javasandboxtest-any-/webapp

下的文件,都是可读的,那么文件权限验证,肯定就必须包含这个路径了。这个安全策略是否可以绕过呢?

开始bypass

这让作者想起了文件下载漏洞。绕过任意文件下载漏洞,有无数前辈的经验,最常见的思路,当然是“/../“了。

读取/etc/passwd文件内容:

http://3.javasandboxtest.sinaapp.com/down.jsp?filename=/data1/jetty_work/84/javasandboxtest/jetty-0.0.0.0-10168-javasandboxtest.war-_3_javasandboxtest-any-/webapp/../../../../../../etc/passwd

一次成功!这种东西真的和运气,有很大的关系!

从这个过程,也进一步验证了SAE的认证代码,checkRead方法,很可能只有一行,下面是推测出来的伪代码:

If (XXXX.startwith(/data1/jetty_work/84/javasandboxtest/jetty-0.0.0.0-10168-javasandboxtest.war-_3_javasandboxtest-any-/webapp))
{
	Return true;
}

这种漏洞,本来就是个经典的文件下载漏洞代码,但是放到沙盒里,却导致了沙盒被绕过。现在我们又可以读取云上用户的文件了。

关于沙盒与JSP空间友好性的问题

我们知道JAVA的web应用,只有jsp和servlet的时代,已经不存在了,无论哪个应用,多少都会有JAVA框架的影子,比如struts、spring等等。框架本身的实现,经常会涉及到getClassLoader等等操作,现在SAE限制了这个东西,作者对STRUTS2应用,能否在SAE上跑起来,表示疑问。为此,作者专门上传了struts的官方showcase上去。
结果返回503错误,不可用。

总结

即使是非常简单的STRUTS2应用都不可用,还有很多其他框架,也都有自己操作classLoader的情况,如果不支持JAVA框架,这样的SAE,还有啥存在的价值呢?所以这些权限,不止简单的禁止了事,它后面还有很多东西要做。没有可用性的安全,不是真的安全,这样的安全处理方案,早晚要在业务的压力下消失不见,要保证可用性,也要保证安全,这才是真正的安全。所以,坐等SAE对classLoader的限制消失,一切回归于0。

最好的办法,是对接管JAVA原生安全验证这部分代码,做一次整体的revuew,在代码无法保证安全之前,就去接管更加安全的东西,这本身就是一种安全隐患了,谁敢讲自己写的代码,一定比SUN(写沙盒的时候,还没到oracle)那帮人更安全,更健壮?

其实沙盒绕过技术,作者也是第一次玩,每次一定要等SAE修补之后,才会有新的办法出现,SAE肯定希望我一次性,把所有绕过的方法都给出来,但是问题是还没做好防御,谈何攻击呢?建议对SAE的代码,做一次整体的review,尤其是接管JAVA沙盒认证这块,相信还有更加严重的漏洞在里面,解决这个问题,只有由安全人员一行一行看了,如果SAE足够开放,建议直接开源出来,这可以更加开放的得到安全信息。
by 空虚浪子心 http://www.inbreak.net 微博:http://t.qq.com/javasecurity

发表评论?

7 条评论。

  1. 高山仰止,518518景行行止vliwtvliwt.

  2. 让诺贝儿奖理事会破天荒地因该帖的出现而开会讨论一直决定今后设立最佳帖子奖的好帖518518dmypk

  3. 玉不琢,不成器;人不学,不知道。学而不思罔,思而不学则殆gycovgycov

  4. 浪子,我不得不给你送上一粟鲜花!

发表评论

Trackbacks and Pingbacks: