Problem

OGNL provides, among other features, extensive expression evaluation capabilities. The vulnerability allows a malicious user to bypass all the protections (regex pattern, deny method invocation) built into the ParametersInterceptor, thus being able to inject a malicious expression in any exposed string variable for further evaluation.

A similar behavior was already addressed in S2-003 and S2-005, but it turned out that the resulting fix based on whitelisting acceptable parameter names closed the vulnerability only partially.
Regular expression in ParametersInterceptor matches top['foo'](0) as a valid expression, which OGNL treats as (top['foo'])(0) and evaluates the value of 'foo' action parameter as an OGNL expression. This lets malicious users put arbitrary OGNL statements into any String variable exposed by an action and have it evaluated as an OGNL expression and since OGNL statement is in HTTP parameter value attacker can use blacklisted characters (e.g. #) to disable method execution and execute arbitrary methods, bypassing the ParametersInterceptor and OGNL library protections.

Proof of concept

Vulnerable Action

Here's an actual decoded example, which will create /tmp/PWNAGE directory:

Solution

The regex pattern inside the ParameterInterceptor was changed to provide a more narrow space of acceptable parameter names.
Furthermore the new setParameter method provided by the value stack will allow no more eval expression inside the param names.

It is strongly recommended to upgrade to Struts 2.3.1.2, which contains the corrected OGNL and XWork library.

In case an upgrade isn't possible in a particular environment, there is a configuration based mitigation workaround:

The following additional interceptor-ref configuration should mitigate the problem when applied correctly, allowing only simple navigational expression:

Beware that the above pattern breaks the type conversion support for collection and map (those parameter names should be attached to acceptParamNames variable).
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

Anonymous

Hello

in short:
In our opinion, the fix from Maurizio Cucchiara is sufficient for the struts default-stack, but custom interceptors can easily (and accidentally) circumvent the fix and leaving the application vulnerable.

The problem:
we have tested the fix in struts 2.3.1.2 which was done by Maurizio Cucchiara with our application.
Surprisingly it was not working in our setup. The reason is, that the changes made at ParametersInterceptor, OgnlValueStack, OgnlUtil and so on do not prevent the dangerous parameter value to be written into the ValueStack (OgnlValueStack).
If the application reads the ValueStack with valueStack.findValue(aKey), the parameter value is evaluated by OGNL and the bogus code becomes executed!

For instance: When an interceptor (or other application code) is simply reading the ValueStack like for debugging purposes, then an attack will succeed!
Here a code snippet from our custom interceptor

The value from the OGNLValueStack in a attack scenario like the above mentioned would look like this:[...] ValueStack [key / value]: [myParameter / (#context["xwork.MethodAccessor.denyMethodExecution"]= new java.lang.Boolean(false), #_memberAccess["allowStaticMethodAccess"]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('notepad'))(meh)]
(Here the Windows Notepad Application gets startet)

Suggestion:
In OgnlUtil.setValue(String name, Map<String, Object> context, Object root, Object value, boolean evalName) the parameterName name is checked to be a value expression (isEvalExpression(...)).
Why not check the parameter value too and throw the OgnlException in case it is a value expression?

We would appreciate any suggestions to solve the problem.
Of course the best would be another improvement of the struts2-ognl-integration