Richfaces 3.x Remote Code Execution

Richfaces version 3.x suffers from a remote code execution vulnerability.

MD5 | 4427edfb92d2e0dd973927a4785c6b81

Original report+advisories:

Unauthenticated Remote Code execution in WebApps using Richfaces 3.X all

RichFaces Framework 3.X through 3.3.4 (all versions) is vulnerable to
Expression Language (EL)
Injection via UserResource resource, allowing an unauthenticated remote
attacker to execute Java
arbitrary code and potentialy OS commanding using a special chain of java
serialized objects
inside a org.ajax4jsf.resource.UserResource$UriData.

PS: others details can be seen on the slides:

The Richfaces expects to receive a serialized resource of the type
via URLs with the pattern:
"/a4j/s/3_3_3.Finalorg.ajax4jsf.resource.UserResource/n/s/{HashCode of the
MimeType Resource}/DATA/{Encoded Serialized Object}".
When this occurs, a check of allowed types is made using a restrict
whitelist (Look-Ahead) in order to
avoid deserialization vulnerabilities.

Following is the Look-Ahead strict whitelist with the allowed types:

1) org.ajax4jsf.resource.InternetResource
2) org.ajax4jsf.resource.SerializableResource
3) javax.el.Expression
4) javax.faces.el.MethodBinding
5) javax.faces.component.StateHolderSaver
6) java.awt.Color

However, although it is not vulnerable to deserialization, it is possible
to construct a special chain
of objects using only allowed types and containing a tainted Expression
Language (EL) in a specific way
that result in it being automatically evaluated by the UserResource class
after the correct deserialization
of the chain (after the cast, not before).

In order to be vulnerable, an application only need to:

1) Use the mediaOutput feature in any point at any time (the attacker don't
need to know where this feature
is used. It just needs that this functionality had been used at any time
by the application).

If the point (1) is satisfied, the application will contains a resource
inside an internal HashMap with the
key like the following:

/----- Resource Name
Key: org.ajax4jsf.resource.UserResource/n/s/-1487394660 <--- HasCode of
resource MimeType (eg "image/jpeg")
/\ /\
| \____
if the resource is of session scope (/s) or not (/n)
if the resource is cacheable (/c) or not cacheable (/n)

The original intent of the UserResource is to create or restore a resource
(like images, flash, audio, etc)
and send it back/draw to the user. So, this is one of the most commons
features used by richfaces web

An attacker can abuse of this feature forcing the application to evaluate
his tainted EL using a chain like
the following:

1] [Obj] org.ajax4jsf.resource.UserResource$UriData
2] [Obj]javax.faces.component.StateHolderSaver
3] [Obj] com.sun.facelets.el.TagMethodExpression
4] [obj] org.jboss.el.MethodExpressionImpl
"${OUR PAYLOAD}" <-----
The malicious EL can be put here.

In the previous chain, notice that all types used are allowed by the
look-ahead protection:

1] "org.ajax4jsf.resource.UserResource$UriData" is an
"InternetResourceBase" that is an "InternetResource"
2] "javax.faces.component.StateHolderSaver" (whitelisted)
3] "com.sun.facelets.el.TagMethodExpression" is an "MethodExpression" that
is and "Expression" (whitelisted)
4] "org.jboss.el.MethodExpressionImpl" is and "MethodExpression"

Notice that the points [2] and [3] of the chain can also be changed in
order to exploit different platforms.

After create the exploit chain, it is needed to encode it properly and make
an HTTP GET in the proper
UserResource URL with the payload.
eg. /a4j/s/3_3_3.Finalorg.ajax4jsf.resource.UserResource/n/n/DATA/{hashCode
of mime}/payload

The {hashCode of MimeType} is not always needed (depends on how the
application uses these features).

When the payload is received by the app, the chain is deserialized and the
UserResource.send() method
is invoked by the ResourceLifecycle.sendResource(). Inside this method, the
content of UserResource$UriData
is restored and our MethodExpression is invoked. Thus, our tainted data
(EL) has reached a taint sink
(MethodExpression.invoke()), leading to the EL evaluation.

Stacktrace example:

org.jboss.el.MethodExpressionImpl.invoke( <-
This contains user controlled data!

PS: You can see PoCs using JBoss and Tomcat in the following video:

In order to demonstrate this vulnerability, we can deploy a richfaces demo
application in a Java Application
Server/Container (eg. JBoss, tomcat, Jetty, WebLogic, etc).

For the PoC, let's use the following configuration:

1) Photoalbum demo application (that uses Richfaces v 3.3.4)
2) JBoss AS 5.1.0.GA <> or JBoss EAP 5.1.2

* Deploying the lab:

1) Get the demo app:
2) Extract the
3) Copy the app in
to the JBoss deploy dir
in jboss-5.1.0.GA/server/default/deploy
<> (for 5.1.0.GA
<>) or jboss-eap-5.1/jboss-as/server/default/deploy (for
5.1.2 eap)
4) Start JBoss Application Server: cd bin ; ./ -b
5) Open the photoalbum index page. Eg.
6) Use the following PoCs (tested in JBoss EAP 5.1.2 and JBoss AS 5.1.0.GA

1) (LINUX) Execute command: touch /tmp/richfaces0day_joaomatosf

2) (MACOS) Open Calculator

PS: before execute the HTTP GET with the PoCs, you need to open the index
page of the app (eg.

PS: Note that for other application servers, you may need to generate other

Since richfaces has reached the end of life, users should apply their own
fix. As a suggestion
users can perform the sanitization of any EL received from the untrusted
sources (tainted) or
even to disable EL evaluation in the Richfaces.

As the execution is triggered internally by the Richfaces lib, you can
follow some paths, eg:
Whenever your application receives a serialized object that will be catched
by the richfaces,
the method getResourceDataForKey of the class ResourceBuilderImpl invokes
the class
LookAheadObjectInputStream which will ensure that only the whitelisted
types can be
deserilized. After that, you can include a second whitelist to ensure that
only trusted ELs
used by your application can be allowed.

RedHat rated this with CVSS3 Base Score 9.8 and issued the cve id

Until now, they released the following advisories about affected products:

Since Richfaces framework is used by many private and opensource projects,
it is very important
to check your assets to ensure that you are not vulnerable.

Joao Filho Matos Figueiredo
Twitter @joaomatosf

JoAPSo F M Figueiredo <>

Related Posts