RichFaces Security Advisory CVE-2013-2165

Brian Leathem

2 minute read

RichFaces

We have fixed a security vulnerability in RichFaces 3, 4 and 5. Details of the vulnerability can be found in this Red Hat Errata document released for our WFK product. We have released community micro releases addressing this vulnerability, so please update your applications ASAP. Read below for a summary of the problem and an explanation of how to use the fix in your applications.

Download RichFaces 3.3.4.Final or RichFaces 4.3.3.Final and use them in your applications to protect yourself from this vulnerability.

The vulnerability

The vulnerability consists of using RichFaces resource deserialisation to trigger the deserialisation methods of any class deployed in the server. The extent of the vulnerability is limited by the classes available, but could potentially let the attacker cause a denial-of-service condition or — in extreme cases — to inject arbitrary code [1].

The fix

The fix involved creating a whitelist of classes that are available to participate in the RichFaces resource deserialisation process. Details of the implementation of the fix are well described in this article on Look-ahead Java deserialization in the IBM developerworks.

The whitelist that ships with RichFaces 3, 4, 5 consist of the classes for the primitive tpyes, as well as classes that implement the following interfaces:

  • RichFaces 3

    • org.ajax4jsf.resource.InternetResource

    • org.ajax4jsf.resource.SerializableResource

    • javax.el.Expression

    • javax.faces.el.MethodBinding

    • javax.faces.component.StateHolderSaver

    • java.awt.Color

  • RichFaces 4, or RichFaces 5

    • javax.faces.application.Resource

    • javax.el.Expression

    • org.richfaces.resource.SerializableResource

    • javax.faces.component.StateHolderSaver

Notice the SerializableResource interface - this is an interface you can implement in your classes to allow them to participate in Richfaces resource deserialisation. This however is not something you will have to do unless you have gotten into some serious resource customisation.

Alternatively, you can copy the resource-serialization.properties file into your own application (using the same package) and add additional interface/class names to the whitelist. This will enable you to have your classes participate in the deserialisation process without needing to compile.

Note: while we have included the patch in RichFaces 5, we have not shipped an update to the RichFaces 5.0.0.Alpha1 release. The fix will be present in an upciming 5.0.0.Alpha2 release.