Summary
Excerpt |
---|
XWork ParameterInterceptors bypass allows remote command execution |
Who should read this | All Struts 2 developers |
---|---|
Impact of vulnerability | Remote server context manipulation |
Maximum security rating | Critical |
Recommendation | Developers should immediately upgrade to Struts 2.2.1 or read the following solution instructions carefully for a configuration change to mitigate the vulnerability |
Affected Software | Struts 2.0.0 - Struts 2.1.8.1 |
Original JIRA Ticket | |
Reporter | Meder Kydyraliev, Google Security Team |
CVE Identifier | |
Original Description | http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote.html |
Problem
OGNL provides, among other features, extensive expression evaluation capabilities (http://www.ognl.org/2.6.9/Documentation/html/LanguageGuide/expressionEvaluation.html). The vulnerability allows a malicious user to bypass the '#'-usage protection built into the ParametersInterceptor, thus being able to manipulate server side context objects.
This behavior was already addressed in S2-003, but it turned out that the resulting fix based on whitelisting acceptable parameter names closed the vulnerability only partially. At least the following context objects are still accessible:
- #context - OgnlContext, the one guarding method execution based on 'xwork.MethodAccessor.denyMethodExecution' property value.
- #_memberAccess - SecurityMemberAccess, whose 'allowStaticAccess' field prevented static method execution.
- #root
- #this
- #_typeResolver
- #_classResolver
- #_traceEvaluations
- #_lastEvaluation
- #_keepLastEvaluation
Solution
As of XWork 2.2.1, now being an integral part of the Struts 2.2.1 release, the ParameterInterceptor was changed to provide a very strict whitelist mechanism for acceptable, non malicious parameter names. Therefore parameters other than simple property navigation paths will be ignored.
Warning |
---|
It is strongly recommended to upgrade to Struts 2.2.1, which contains the corrected XWork library. |
In case an upgrade isn't possible in a particular environment, there is a configuration based mitigation workaround:
Possible Mitigation Workaround: Configure ParametersIntercptor in struts.xml to Exclude Malicious Parameters
The following additional interceptor-ref configuration, suggested by John Wilander, should mitigate the problem when applied correctly:
Code Block |
---|
<interceptor-ref name="params"> <param name="excludeParams">dojo\..*,^struts\..*,.*\\.*,.*\(.*,.*\).*,.*@.*</param> </interceptor-ref> |
Note | ||||
---|---|---|---|---|
| ||||
For this configuration to work correctly, it has to be applied to any params interceptor ref in any stack an application is using. |