|Home > Security Bulletins > S2-009|
ParameterInterceptor vulnerability allows remote command execution
Who should read this
All Struts 2 developers
Impact of vulnerability
Remote command execution
Maximum security rating
Developers should immediately upgrade to Struts 220.127.116.11 or read the following solution instructions carefully for a configuration change to mitigate the vulnerability
Struts 2.0.0 - Struts 18.104.22.168
Meder Kydyraliev, Google Security Team
Reported directly to email@example.com
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.
Here's an actual decoded example, which will create /tmp/PWNAGE directory:
And the JUnit version
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.
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: