#Primeface vs icefaces vs richfaces code#

It describes that the RichFaces Showcase application utilizes the MediaOutputResource dynamic resource builder. The RichFaces issue RF-13977 corresponding to this vulnerability is public and actually quite detailed. Due to several aftereffects, the list was extended occasionally. The arbitrary Java deserialization was patched in RichFaces 3.3.4 and 4.3.3 by introducing look-ahead deserialization with a limited set of whitelisted classes. This can be exploited with ysoserial using a suitable gadget. That method then decodes and decompresses the data in a similar way and finally deserializes it without any further validation.

In RichFaces 4.x, it is basically the same: the holds the request data passed via db/ do and codeObjectData(String) is used in the latter case. If the requested resource key begins with /DATA/, the remaining data gets decoded and decompressed (using crypt(byte), which actually, despite its name, does not incorporate encryption ) and finally deserialized without any further validation. When a RichFaces 3.x resource is requested, it eventually gets processed by ResourceBuilderImpl.getResourceDataForKey(String). This vulnerability is a straight forward Java deserialization vulnerability. CVE-2013-2165: Arbitrary Java Deserialization In all cases, the binary data is compressed using DEFLATE and then encoded using a URL-safe Base64 encoding. In RichFaces 3.x, the data gets appended to the URL path preceded by either /DATB/ (byte array) or /DATA/ (Java serialized object stream) in RichFaces 4.x, the data is transmitted in a request parameter named db (byte array) or do (Java serialized object stream). The provided data is either interpreted as a plain array of bytes or as a Java serialized object stream.

#Primeface vs icefaces vs richfaces code#

CVE-2015-0279: Arbitrary EL Evaluation in RichFaces 4.x ≤ 4.5.3 ( RF-13977) Injection of arbitrary EL method expressions in allows remote code execution.īoth vulnerabilities rely on the feature to generate images, video, sounds, and other resources on the fly based on data provided in the request. In the past, two significant vulnerabilities have been discovered by Takeshi Terada of MBSD, which both affect various RichFaces versions: CVE-2013-2165: Arbitrary Java Deserialization in RichFaces 3.x ≤ 3.3.3 and 4.x ≤ 4.3.2 Deserialization of arbitrary Java serialized object streams in allows remote code execution. The latest releases of the respective branches are 3.3.4 and 4.5.17. In early 2016, the developers of RichFaces announced the end-of-life of RichFaces in June 2016. However, as 5.x has never left alpha state, it is rather irrelevant. RichFaces has three major version branches: 3.x, 4.x, and 5.x.

RichFaces is one of the most popular libraries among these component libraries and since it became part of JBoss (and thereby also part of Red Hat), it is also part of several JBoss/Red Hat products, for example JBoss EAP and JBoss Portal. e., Apache MyFaces and Oracle Mojarra), there are several component libraries, which provide additional UI components and features. While there are only two major JSF implementations (i. JavaServer Faces (JSF) is a framework for building user interfaces for web applications. Thereby, all RichFaces versions including the latest 3.3.4 and 4.5.17 are vulnerable to RCE. Code White discovered two new vulnerabilities which bypass the implemented mitigations. In the past, two vulnerabilities (CVE-2013-2165 and CVE-2015-0279) have been found that allow RCE in versions 3.x ≤ 3.3.3 and 4.x ≤ 4.5.3. RichFaces is one of the most popular component libraries for JavaServer Faces (JSF).