SailPoint IdentityIQ Response to log4j Remote Code Execution Vulnerability

IdentityIQ (IIQ) IIQ Discussion and Questions
1

IMPORTANT: Please see the latest announcement here.

SailPoint has fully mitigated the Log4J RCE vulnerability (CVE-2021-44228) in all impacted products.

We are aware of the recently-identified Log4J DoS vulnerability (CVE-2021-45046) that is also applicable to the impacted products. While this new DoS vulnerability has a low severity (CVSS score of 3.7 per NVD), we are actively working on addressing this vulnerability by upgrading to Log4J 2.16.0 and expect product releases that include the updated library to be available in the coming days.

We will be issuing further communications once this issue has been addressed. No action is needed at this time.
IdentityIQ 8.0 and later (and all patch levels for those versions) is susceptible to the log4j RCE vulnerability. IdentityIQ 7.3 and earlier is likely susceptible only if customers have configured the use of a JMSAppender (this is not configured out of the box and not a likely configuration). Our immediate mitigation strategy is to provide a blog post that indicates we are vulnerable and provides information on configuring the Java system property to remove the vulnerability. Our mid-term mitigation strategy (within 30 days per our Product Vulnerability Management policy) will be to deliver an updated log4j library that will permanently mitigate the issue.

The instance of Elasticsearch in FAM is susceptible to this vulnerability. Public documentation indicates that the version of log4j in that environment cannot have the vulnerability mitigated with a system property, so the library will need to be updated. We are working on determining the best way for that to happen (whether we can do it in official packaging or whether it will have to be done manually by the customer). It is not clear at this time how much user-defined input (including data from managed systems like file names or file content) can make it into Elasticsearch logging based on where this component is in the stack.

As an aside, our testing has shown that the information indicating later versions of the JDK prevent this vulnerability from occurring have not proven to be true. Public discussion about this vulnerability is still pretty raw, so not everything you read on the internet is true. Who’da thunk it.

4 Likes
3

Thank you for explanation.
Apache has released Log4j 2.15.0 RC2 to address this severity. Please suggest.

4

A critical vulnerability in the log4j library used in IdentityIQ was announced and is being tracked by CVE-2021-44228.

SailPoint has reproduced this vulnerability and determined that IdentityIQ 8.0 and later is susceptible to remote code execution because of it. The level of risk is highly dependent on the components and level of logging that are configured for IdentityIQ in the deployed environment. Some IdentityIQ components receive user-defined input prior to authentication, so this vulnerability could be exploited in some environments before successful authentication to IdentityIQ.

This vulnerability can and should be immediately mitigated by introducing a JVM system property to all IdentityIQ runtime environments including the application server hosting the IdentityIQ server, the IdentityIQ console, and the IdentityIQ Cloud Gateway (not all customers use the IdentityIQ Cloud Gateway). Specifically, as documented in the content for the CVE referenced above, setting log4j2.formatMsgNoLookups to true will prevent the vulnerability from being exploited. This is typically configured in the application startup scripts by defining JVM options or arguments to include -Dlog4j2.formatMsgNoLookups=true as a JVM command line argument.

For the application server environment hosting the IdentityIQ server (Tomcat, JBoss, WebSphere, WebSphere Liberty, or WebLogic), please consult the application server documentation for guidance on the most appropriate method for setting JVM system properties for your deployment configuration. This could be modifying an environment variable in a startup script, modifying directives in a configuration file, or using a CLI command to make changes. In almost all cases, the application server will need to be re-started for the change to take effect.

For the IdentityIQ console launch script in WEB-INF/bin/iiq and WEB-INF/bin/iiq.bat, modify the script to add the JVM argument -Dlog4j2.formatMsgNoLookups=true to the LAUNCHER_OPTS environment variable.

For customers that utilize the IdentityIQ Cloud Gateway to create a distributed connector deployment architecture, modify the bin/catalina.sh or bin/catalina.bat startup script in the Tomcat instance that hosts the Cloud Gateway to add the JVM argument -Dlog4j2.formatMsgNoLookups=true to the JAVA_OPTS environment variable.

IdentityIQ 7.3 and earlier is not susceptible to this vulnerability as long as an appender that uses JMSAppender is not in use. Inspection of WEB-INF/classes/log4j.properties will show the appenders that are configured.

The IdentityIQ Connector Gateway used for mainframe connectivity is not susceptible to this vulnerability as long as an appender that uses JMSAppender is not in use. Inspection of log4j.properties will show the appenders that are configured.

Other Windows-based IdentityIQ components (Desktop Password Reset, Active Directory Password Interceptor, and IQService) are not susceptible to this vulnerability since they do not use the Java log4j library.

At a future date, SailPoint will provide security fixes to update the log4j library to version 2.15.0 or later to permanently remove the vulnerability, but the JVM system property described above is an equivalent resolution that can and should be immediately applied.

The entire SailPoint team is available to answer any question you may have about this vulnerability or how to proceed with the mitigation steps. If you have questions, please contact your Customer Success Manager, Engagement Manager, or Partner Manager.

2 Likes
5

For anyone else seeing this: Also note the section in the Compass post about the IIQ console script that appears to be absent here:

The IdentityIQ console launch script in WEB-INF/bin/iiq and WEB-INF/bin/iiq.bat should be modified to add the JVM arguments described above to the LAUNCHER_OPTS environment variable.

1 Like
6

@derek_kuhnert, great catch! I updated the solution above with the update you saw in Compass. Unfortunately, not all developers here have access to compass so we wanted to be sure to cross-post so everyone could see the content.

7

IQService should not be affected for obvious reasons, but what about the Mainframe ConnectorGateway? It appears to be using log4j v1, so should not be affected under the premise no changes were made to its default config (appender that uses JMSAppender), correct?

8

Your conclusions are correct.

The log4j 1.2.x version included in the Connector Gateway is not susceptible to the vulnerability documented by CVE-2021-44228 unless an appender is created using the JMSAppender. Visual inspection of the Connector Gateway log4j.properties can determine if JMSAppender is used.

1 Like
9

Is there an example that can be provided for the syntax needed for iiq and iiq.bat? Is there also a way to verify this when launching the console?

10

In iiq.bat you would change the JAVA_OPTS line to include -Dlog4j2.formatMsgNoLookups=true property.

set JAVA_OPTS=-Xms128m -Xmx256m -Dsun.lang.ClassLoader.allowArraySyntax=true -Dlog4j2.formatMsgNoLookups=true

11

Do we need to also do it in the LAUNCHER_OPTS or just the JAVA_OPTS variable.

12

Hi Jordan,

Someone mentioned below that it needs to be added to JAVA_OPTS. Can you confirm if this is the case. Just trying to figure out all locations that this needs to be added.

Thanks

13

Hi all,
what about SecurityIQ? Is SecurityIQ also impacted by this vulnerability?
If so, which versions are impacted and how to address the vulnerability?

Thanks in advance for your support.
Regards,
Paolo S.

14

@GreeneT the short answer is yes. I’ve revised my initial response (the one marked as the solution as this topic) with an update from the IIQ team.

2 Likes
15

@paolosalatinos Here is the response from the IIQ tema regarding SecurityIQ:

This vulnerability can and should be immediately mitigated by updating the log4j library in the Elasticsearch instance that is part of the File Access Manager deployment as documented in the content for the CVE referenced above. An e-fix containing updated libraries and a README with installation instructions is attached to this blog post.

The entire SailPoint team is available to answer any question you may have about this vulnerability or how to proceed with updating the libraries. If you have questions, please contact your Customer Success Manager, Engagement Manager, or Partner Manager.

2 Likes
16

The newly discovered DoS vulnerability CVE-2021-45046 should not affect IIQ since the default log4j configuration is using none of the mentioned lookups or patterns and I imagine the same is true for FAM, correct?

17

As of the latest updated information from LunaSec enabling formatMsgNoLookups does not prevent all vulnerabilities. Will Sailpoint update their response?

Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228 & CVE-2021-45046) | LunaSec

1 Like
18

Echoing what robbe posted. What’s the next step to mitigate now that formatMsgNoLookups=true doesn’t address the issue completely? This is based off: CVE - CVE-2021-45046 impact

1 Like
19

Hi jordan,
many thanks for your support.

Kind regards,
Paolo

20

Efix , am I missing something for securityIQ FAM , I only see the 3 links no read me .tia

22

@joel_prefontaine, great timing. You can see our latest announcement here which includes FAM: Log4J Remote Code Execution (RCE) and Denial of Service (DoS) Vulnerabilities Update - December, 17 2021 - #2