Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-16771

Remove bcel from jboss/xalan-j binaries (Fix CVE-2022-34169)

    XMLWordPrintable

Details

    Description

      https://access.redhat.com/security/cve/CVE-2022-34169 is a CVE resolved in OpenJDK via changes like https://github.com/openjdk/jdk8u/commit/3dca446d440e55cbb7dc3555392f4520ec9ff3bc. The artifacts produced from the jboss xalan-j fork at https://github.com/jboss/xalan-j/tree/jboss_2_7_1, however, have analogous code to what was fixed in OpenJDK, via the shading of Apache BCEL into the xalan-j jar.

      Apache BCEL, which is shaded into upstream Apache Xalan-J applied the equivalent fix:

      https://github.com/apache/commons-bcel/commit/f3267cbcc900f80851d561bdd16b239d936947f5

      However, JBoss EAP is not impacted by this CVE, since the xalan-j artifact productized by Red Hat does not include the shaded in bcel. Therefore there is not need to incorporate that commons-bcel change into EAP's xalan-j component.

      Given that EAP and WildFly have been used for very similar use cases for years now, it seems clear that there's no need to shade in bcel to handle WildFly uses of xalan-j, so I think the fix for this in jboss/xalan-j is to stop doing that. The use case for jboss/xalan-j is to provide a Xalan impl specifically for WildFly's internal needs.

      Attachments

        Issue Links

          Activity

            People

              bstansbe@redhat.com Brian Stansberry
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: