IdentityIQ log4j Version Verification

[#1]

Introduction

Part of the deployment process for any release of IdentityIQ should include a test plan to validate that the deployment contains the desired changes.

For all releases of IdentityIQ including releases, patches, e-fixes, and security fixes, detailed information about the product runtime can be found in the web user-interface at debug/about.jsf when accessed by an IdentityIQ user with the System Administrator capability.  This page shows information for the specific application server that the browser connects to, so in a deployment with multiple application server instances, if there is not a high level of confidence in build and deployment procedures creating consistent instances, you should iterate through visiting each application server instance including servers in the UI and task tier.

IdentityIQ log4j Version Verification

Remediation steps defined in Log4j vulnerabilities documented in CVE-2021-44228, CVE-2021-44832, CVE-2021-45046, and CVE-2021-45105 define that Log4j should be updated to version 2.17.1. The security fixes released by SailPoint for our products provide that upgrade.

The following steps can be used to create and run a rule that will show the Log4j version in use in an IdentityIQ 8.0 and later instance.

1. Save the XML document provided below into a file.
2. Login to IdentityIQ as a user with the System Administrator capability,
3. Use Import from File on the Gear Icon -> Global Settings page to import the rule definition and create the rule.
4. Visit debug/debug.jsf, select the rule named Log4j 2 Version in the rule list selection component, and click Run Rule.
5. Validate that the results displayed when running the rule show 2.17.1:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE String PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<String>2.17.1</String>

6. Repeat this process for each application server in the deployment including servers in the UI and task servers.

Log4j 2 Version Validation Rule

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">

<sailpoint>

  <Rule language='beanshell' name='Log4j 2 Version'>
    <Signature returnType='String'>
      <Inputs>
        <Argument name='context'>
          <Description>
            A sailpoint.api.SailPointContext object that can be used to
            query the database to aid in correlation.
          </Description>
        </Argument>
        <Argument name='log'>
          <Description>
            log for debugging
          </Description>
        </Argument>
      </Inputs>
      <Returns>
        <Argument name='version'>
          <Description>
            The Log4j 2.x version
          </Description>
        </Argument>
      </Returns>
    </Signature>
    <Source>
      <![CDATA[
        String version = org.apache.logging.log4j.util.PropertiesUtil.class.getPackage().getImplementationVersion();

        return version;
      ]]>
    </Source>
  </Rule>

</sailpoint>

[twistedbow]

thx. wondering if there'll be a fix for log4j 2.17?

[danieldohertyrtx]

@twistedbow or anyone Will this work for determining Log4j version on Cloud Gateway servers?

[magesh_narayanan]

The e-fix zip contains the older version of log4j jar files? Our vulnerability team is asking us to remove those older version of log4j jar files. Also, the identityiq.war file that ships with IIQ 8.2 also contains the older version of log4 jar files. Though we verified with the rule to make sure IIQ is using the  2.16 version, can you please clarify on whether the presence of older version jar files is a cause of concern or not?  Thanks

[magesh_narayanan]

The e-fix zip contains the older version of log4j jar files? Our vulnerability team is asking us to remove those older version of log4j jar files. Also, the identityiq.war file that ships with IIQ 8.2 also contains the older version of log4 jar files. Though we verified with the rule to make sure IIQ is using the  2.16 version, can you please clarify on whether the presence of older version jar files is a cause of concern or not?  Thanks

[david_crow]

@magesh_narayanan As described in the README file that accompanies the security fixes associated with IIQCB-4601, because the standard and most common way for e-fix and patch installation in IdentityIQ is to overlay files on top of an installation, there is not an automated mechanism for removing files.  To perform the equivalent, SailPoint provides skeleton versions of the old files that merely contain a jar manifest and a README (which includes the text "This library has been replaced by log4j-1.2-api-2.16.0.jar").  The old files with the same name as vulnerable files do not contain any code and therefore are not vulnerable.  This practice is always used when a library is updated in a patch or e-fix.

For organizations that are required to not have any files with names the same as vulnerable jar files, the mechanism you use to create deployable application artifacts will determine the appropriate course of action.  If you are creating a war file or deployment directory by hand, then you can remove the old files prior to deployment.  If you are using an automated tool such as the SSB, then you will need to either 1) remove the files from the release war and e-fix files used as input to the build, or 2) remove the files from the war file that the build generates.  If you are using other tools, then you will need to adjust as necessary.  As always, a test plan to insure that your build has the contents you desire is important.

[david_crow]

@twistedbow Information about SailPoint's plans with relation to Log4j 2.17 will be announced in the Community Announcements blog.

[david_crow]

@danieldohertyrtx The rule must run in the context that the check is desired.  To have a rule such as this work for the Cloud Gateway, a connector-based rule would need to be used and the output would have to somehow be captured.  This is possible, but not straightforward.  Visual inspection of the deployment artifacts (i.e. file contents of the webapps/CloudGateway as well as the entire Tomcat installation) is the best mechanism for validation in that environment.

[klbumgar]

Has any one got the patch to build? We removed the non 2.16 files and now the build is failing. 

[david_crow]

@klbumgar I would post this in the IdentityIQ forum instead of as a comment to this post.  You will get more eyes on the request for assistance.  You will need to include more information about how you removed the non-2.16.0 files and more information about what "build is failing" means.

[klbumgar]

@david_crow I'm happy to say after restarting and being a little more careful we were able to get it to build in our Non-production environments. We have successful implemented the eFix in our production environment.