Friday, April 11, 2014

RichFaces Security Advisory CVE-2014-0335

RichFaces

A security vulnerability has been uncovered and resolved in RichFaces 4. Details of the vulnerability can be found in this Red Hat Errata document released for our WFK product. We have released a community micro release addressing this vulnerability, so please update your applications ASAP. Read below for a summary of the problem and some additional minor fixes included in this release.

To update to this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.3.6.Final. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

The issue

The issue was reported and resolved through community efforts in RF-13250. Much thanks to Marcel Šebek for both investigating and patching this issue!

The vulnerability

The vulnerability manifests itself when malformed Atmosphere requests cause RichFaces to leak memory. This memory leak can be exploited via a large number of requests to a push-enabled RichFaces application leading to an out-of-memory error, and a corresponding DDoS on the underlying application server.

This 4.3.6.Final release of RichFaces no longer leaks memory leak when receiving malformed Atmosphere requests. Users are encouraged to update their deployed RichFaces applications, particularly those that are push-enabled.

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

Other fixes

Check out the 4.3.6.Final release notes for a complete list of issues resolved in this release. The issues for the most part are stabilizations to our Photoalbum demo. However some noteworthy issues include:

  • RF-13531: selects: cannot select option on IE11

  • RF-13559: a4j:commandButton wrong actions performed

  • RF-13540: Websphere incarnation of MyFaces renders optimized resources multiple times

Next Steps

We are hard at work putting out a RichFaces 4.5 release to address JSF 2.2 compatibility with the RichFaces 4.x branch. This has necessitated we put RichFaces 5 development on hold, but we feel will be worth it to get JSF 2.2 support in a stable release sooner rather than later.


Tuesday, July 16, 2013

RichFaces Security Advisory CVE-2013-2165

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.