转载

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

0x00 前言

这个漏洞已经出来很久了,以前简单分析过,但是由于时间关系,没能深入研究原理,网上对这个漏洞的分析也不太多,最近由于工作原因,深入分析了一下这个漏洞的原理,这里重点将漏洞调试过程,以及一些之前遇到的一些奇怪问题的原因记录下来。

首先来看一下官方对这个漏洞的描述,如下图:

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

可以看到,这个漏洞的形成,是因为在早于JSP2.0的版本上,由于没有EL表达式的支持,Spring标签为了兼容这部分版本,Spring的一部分标签独立于Servlet/JSP容器添加了对EL表达式的支持。但这样做引起了一个问题,就是当这部分标签在支持EL表达式的容器中运行的时候,Spring标签的属性会被当做EL表达式执行两次,第一次是被容器当做EL执行,第二次是被Spring标签自身执行。所以,如果攻击者可以控制标签属性的内容,就可以执行自己提交的EL表达式,会造成信息泄露、代码执行等风险。

0x01 漏洞原理

首先编写一段测试JSP代码,并且引入存在漏洞的Spring标签,我这里使用的是Tomcat 7.0.57和Spring 3.0.5

#!html <%@ taglib uri="http://www.springframework.org/tags" prefix="spring"%> <spring:message  text="${param.a}"></spring:message> 

这里使用message标签,text属性用el表达式从请求参数中取值,这样当访问

http://localhost/tag.jsp?a=${applicationScope} 

${applicationScope}这个字符串,就会被当做EL表达式执行,如下图

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

下面我们就从代码中,研究一下这个漏洞的原理。

首先,${param.a}这个EL表达式要在JSP里面执行,这里有必要简单说一下JSP的执行原理,tag.jsp在执行的时候,会先通过规则变成tag_jsp.java,这个文件可以在tomcatRoot/ work/Catalina/localhost/项目名称/org/apache/jsp/路径下找到,这个类其实是一个servlet,通过查看这个文件的代码,我们可以发现${param.a}这个EL表达式,其实是被转化成了这样的代码org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${param.a }", .......),这行代码调用了Tomcat的一个专用方法来执行EL表达式,这段代码执行了之后,我们通过请求参数提交的${applicationScope}就被容器获取,并且传入了Spring标签,如下图:

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

还需要说一下关于标签的一些内容,标签都有一个tld文件,这个文件里面有标签的各种信息,包括标签实现类、属性信息等等,这个标签对应的spring.tld文件可以在Spring的jar包中找到,打开这个文件搜索message,就可以定位到如下图的位置:

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

从上面可以看到org.springframework.web.servlet.tags.MessageTag就是这个标签的实现类,关于标签的规范,我就不多说了,有兴趣的朋友可以去翻翻相关的规范。

Debug程序,在doStartTagInternal方法下断点,如下图:

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

然后跟进resolveMessage方法,因为程序执行到这里,容器已经第一次执行了EL表达式${parm.a},将参数值${applicationScope}取了出来,可以看到text变量,这时候就是我们传入的${applicationScope},如下图:

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

最后跟踪到org.springframework.web.util.ExpressionEvaluationUtils类的evaluateExpression方法,在这里可以看到Spring的代码调用了getExpressionEvaluator方法获取了容器执行El表达式求值对象,并执行了EL表达式,到这里可以看到我们通过请求参数提交的字符串,被当做EL表达式执行了,如下图:

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

从上面的过程可以看到,容器第一次执行EL表达式${param.a}获得了我们输入的${applicationScope},然后Spring标签获取容器的EL表达式求值对象,把${applicationScope}再次执行掉,形成了漏洞。

0x02 Tomcat不能远程代码执行研究

这个漏洞既然能执行攻击者提交的EL表达式,那么获取敏感信息、XSS等攻击自然不是问题,我这里主要说一下代码执行的一些问题。 这个漏洞之所以能造成远程代码执行,是因为从JEE6开始,EL(EL2.2)表达式不仅支持获取对象属性,还加入了对方法调用的支持,而Tomcat、Resin等容器都加入了EL表达式对方法调用的支持,之前知识库里面已经有大牛公布的针对Resin和GlassFish的代码执行POC,虽然由于容器对EL表达式的执行实现上有差异,每个容器POC有所差异,但是都可以成功实现方法调用,我这里就不多说了,而我在最初测试这个漏洞的时候,发现Tomcat始终没法调用方法,当时没有深入研究,通过前面的分析,其实原因已经可以看出来了,这里还是测试一下,先写一段JSP测试代码:

#!html <body> ${“aaa”.replace(‘a’,’b’)} </body> 

打开这个页面,发现a都已经被b替换,说明replace方法被成功调用:

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

但是当我们通过之前的tag.jsp尝试提交http://localhost/tag.jsp?a=${“aaaa”.replace(‘a’,’b’)}的时候却爆出了错误,如下图:

Spring框架标签EL表达式执行漏洞分析(CVE-2011-2730)

从Tomcat 7开始已经支持EL表达式方法调用,为什么第二次会失败呢?

其实前面的分析中已经看到,在JSP中直接写EL表达式,Tomcat调用了org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate方法,这个方法已经加入了对EL表达式方法调用的支持,而通过Spring标签执行EL表达式,前面已经看到是通过pageContext的getExpressionEvaluator方法,而在EL表达式的新标准中这个方法已经“废弃”,Tomcat并没有在这个方法的实现中加入对方法调用的支持,所以造成执行失败,这也让这个漏洞在Tomcat上显得有点鸡肋了,谁能保证Tomcat哪天不会抽风,改变代码呢?说不定到时候,这个漏洞,就可以在Tomcat上造成代码执行了。

参考

http://support.springsource.com/security/cve-2011-2730

http://drops.wooyun.org/tips/2892

正文到此结束
Loading...