All of the third-party libraries that are used by ICEfaces were reviewed and assessed. Some of them were updated to newer versions while others were patched and others weren't modified. The main criteria for these decisions were security and stability. Security updates are an important aspect of ICEfaces patch releases, and they received special attention in this effort. And the stability that ICEfaces provides is also a quality that we want to preserve. As a result some libraries were only patched, while for some other libraries we determined that it was best not to change them. The following is a summary of the work done:

The POI library, used for data exporting in XLS and XLSX formats, was updated to the latest available library, from 4.1.2 to 5.3.0. All its dependencies were updated as well to the prescribed versions in the release notes and in the Maven POM file. While the POI 4.1.2 library didn't have any vulnerabilities reported, some of its dependencies did have a few vulnerabilities reported. With this update, there are now no known vulnerabilities in the POI library used by ICEfaces nor in its dependencies, as of this writing.

The iText library was updated from version 2.1.7 to version 5.5.13.4. The old version has one known vulnerability, while the new version doesn't have any vulnerabilities. However, the package names changed slightly from com.lowagie.* to com.itextpdf.*. Any application doing something custom with the old library (such as a custom exporter or pre-processors and post-processors) will have to update the imports of their custom code, if they decide to update to the newer library. A mechanism was implemented for the exporter components to use either the newer library or the older library, in that order of precedence, if available. So, the old iText library can continue to be used as usual, if desired.

Research to find new vulnerabilities in the jQuery and jQuery UI libraries was performed and no new vulnerabilities were found for jQuery and 3 new vulnerabilities were found for jQuery UI. Their respective fixes were applied in our code. More information can be found in this other JIRA ICE-11564.

Likewise, research to find new vulnerabilities in the CKEditor (ace:richTextEntry) was conducted, and two new vulnerabilities were found since the last update. The fixes were applied to our code. More information can be found in this other JIRA ICE-11563.

The rest of the libraries remained the same. They can be classified in 3 categories: core libraries, build-time libraries, and minor Javascript libraries.

The core libraries are mainly Mojarra JSF and Myfaces and its dependencies. They have remained the same for several years for stability reasons.

None of the build-time libraries pose any security risks for application developers using Icefaces.

As for the remaining minor Javascript libraries, which are used for specific components individually, no vulnerabilities were found in them, and they are no longer maintained by their original developers. We assessed their code for good measure and found no reasons for concern.

Even without the updates and fixes described above, the ICEfaces framework has always been very secure due to its fundamental approach of rendering the markup in the server and validating and sanitizing all user input before using it. All of the Icefaces components have been designed carefully to avoid security issues. As long as the third-party libraries included in ICEfaces are only used for their original purposes (i.e. by the ICEfaces components only) applications developers can have peace of mind that their applications are secure.

More details about the iText library update.

The iText library that we used (2.1.7) was the last of its product line for quite some time. A newer product line called iText Core is being published now, which is incompatible with the legacy product line of iText that we use. The version 4.2.0 of this legacy product line was incorrectly added to the Maven repository by another company that forked the code. Eventually, the company that originally created iText published versions 5.x of this legacy product line again, which to this day continues to receive security updates. The only difference is that the package names changed from com.lowagie.* to com.itextpdf.*. Other than that, no other changes are needed, and the updated library continues to work normally with existing code that uses it. We tested thoroughly our exporter components for PDF exporting and found no issues.

The vulnerability that was eliminated is CVE-2017-9096.

Since we don't include the iText library in ICEfaces due to licensing reasons, we use Java Reflection to make use of this library, if it's present in the class path. We added a mechanism to look for the newer library, and if it's not found, the code looks for the old library (and if it's not found either, the export operation is simple cancelled gracefully). So, it's possible to use either the newer or the older iText library on an ICEfaces application. However, if the application has some custom code that makes use of the iText library, its imports should be updated to the new package names, if the newer library is to be used.

More related information can be found in the following URLs:

https://stackoverflow.com/questions/62329351/pom-xml-error-missing-artifact-com-lowagieitextjar4-2-2-how-dowload-itext

https://security.snyk.io/package/maven/com.itextpdf%3Aitextpdf

https://central.sonatype.com/artifact/com.lowagie/itext/4.2.2?smo=true

https://itextpdf.com/blog/technical-notes/my-maven-build-broken-what-should-i-do