Summary

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

WW-3470, XW-641

Reporter

Meder Kydyraliev, Google Security Team

CVE Identifier

CVE-2010-1870

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.

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:

<interceptor-ref name="params">
    <param name="excludeParams">dojo\..*,^struts\..*,.*\\.*,.*\(.*,.*\).*,.*@.*</param>
</interceptor-ref>

For this configuration to work correctly, it has to be applied to any params interceptor ref in any stack an application is using.
E.g., if an application is configured to use defaultStack as well as paramsPrepareParamsStack, you should copy both stack definitions from struts-default.xml to the application's struts.xml config file and apply the described excludeParams configuration for each params interceptor ref, that is once for defaultStack and twice for paramsPrepareParamsStack

  • No labels