ALM mitigation of 'log4j' compromise - CVE-2021-44228

2 Likes

About this vulnerability:
The zero-day critical vulnerability of Apache Log4j2 is disclosed recently, and the CVE is published as CVE-2021-44228. For details see: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- Apache Log4j2 is a Java-based logging library which is used by ALM and Octane application server and QIS (AKA: Global Search).
 
Security Impact:
- The issue concerns a case of unauthenticated, remote code execution (RCE). It is possible to execute malicious code and allow a complete takeover of vulnerable systems.
 
Affected Products:
- ALM/QC 15.5.0, 15.5.1 (SP1), 15.5.1 Patch 01, 15.5.1 Patch02, 16.0.0
- ALM Quality Insight – 1.0
- ALM Global Search - 15.5, 15.0.1, 12.60
Note: Global Search and Quality Insight are independent services which require separate installation from ALM

Products not affected:
- ALM Synchronizer (a.k.a: Gossip)
- ALI, EI, MC extensions
- Jira plugin
- ALM Explorer, ALM Client launcher, WebRunner, QoT, MSI Generator

Mitigation Plan:
- For affected ALM versions, the previously indicated mitigation approach of disabling the log4j2 lookup feature is insufficient to handle this CVE. For information, see https://nvd.nist.gov/vuln/detail/CVE-2021-45046
    
- We strongly advise you to mitigate this issue by using the hotfix that updates Log4j to version 2.17.1. For more information, please go to this link

- For the affected Quality Insight and Global Search, please follow instructions:
  - Global Search
  - Quality Insight
  - For ALM SaaS, all servers are patched

Summary of recent vulnerabilities and recommended mitigation method:
- CVE-2021-44228:
  - Update Log4j to version 2.16 and later, 
link

- CVE-2021-45046:
  - Update Log4j to version 2.16 and later, 
link

- CVE-2021-45105: 
  - ALM/Quality Center does not use the "non-default Pattern Layout with a Context Lookup" in Log4j in default configuration settings, so ALM is not affected, however, if the user customized the configuration and used this function, please review the mitigation method from here


If assistance in implementing the mitigation is needed please open a support ticket with Micro Focus Support

Labels:

Support Tip
Comment List
Anonymous
  • There are API changes from log4j 1.x to 2.x, so we cannot simply replace them. We cannot delete them either, since they are used by the product. So, my suggestion is, 1. upgrade to 15.5 or higher version on which you can upgrade log4j manually to the highest version (hotfix); 2. wait for the 15.0.1 formal patch which is scheduled on April 2022.

  • Understand the log4j does not affect 15.01 (currently installed); however, my company is adamant we upgrade to 2.17. For 15.01 installations, what is the file used for in our installation and can we delete the file? There's only the log4j.jar in our installation, none of the -api or -core files on our system.

    If we cannot delete the files, is there a way to upgrade them? Thanks.

  • That is, Microfocus does not seem to offer this "connection" between ALM and Eggplant; please tell me if I am wrong. If this is the case, you may wish to inquire with the vendor that offers this option.

  • The "C:\Program Files (x86)\eggplant-alm" is for the connection we have between Eggplant and ALM for test runs.

    So on the CVE-2021-4104 where ALM does not support JMSAppender we should see that as a "False/Positive" from the Tenable scan then?

  • Hi, i noticed that there are several products running your environment, and let's take it one by one:

    For Autopass please refer to: https://portal.microfocus.com/s/article/KM000003074?language=en_US

    For ALM 12.53, with the path E:\Program Files\HP\ALM\ in your case, CVE-2021-4104 states that "Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default." and because ALM does not support JMSAppender, ALM (versions lower than 15.5) is not impacted by CVE-2021-4104.

    I am aware of a path "C:\Program Files (x86)\eggplant-alm" that appears to be unrelated to a Microfocus product; could you help verify and clarify?

  • Reference:

    CVE-2021-44228 is the vulnerability for Log4j versions 2.0-2.14.

    CVE-2021-4104 is the vulnerability for Log4j version(s) 1.x.

    As we assessed our exposure to the Log4j vulnerability, we used our vulnerability scans to discover that your application, HP Application Lifecycle Management v12.53, uses a 1.x version of Log4j. While we understand that not all 1.x versions are vulnerable (CVE-2021-4104), if the JMSAppender is used and configured to perform a JNDI lookup, we are at risk. We are asking you to inform us whether your software is at risk and if you have developed a patch that we may immediately deploy.

    To aid in your assessment, here is the technical detail that we received back from our Tenable vulnerability scan:

    • Apache Log4j<2.15.0 Remote Code Execution (Windows)
      1. Path: E:\Program Files\HP\HP AutoPass License Server\HP AutoPass License Server\HP AutoPass License Server\webapps\AutoPass\WEB-INF\lib\log4j-1.2.15.jar
        • Installed version: 1.2.15
        • Fixed version: 2.15.0
      2. Path: E:\Program Files\HP\UFT\HP AutoPass License Server\HP AutoPass License Server\webapps\AutoPass\WEB-INF\lib\log4j-1.2.15.jar
        • Installed version: 1.2.15
        • Fixed version: 2.15.0
      3. Path: C:\Program Files (x86)\eggplant-alm\lib\log4j-1.2.17.jar
        • Installed version: 1.2.17
        • Fixed version: 2.15.0

     

    • Apache Log4j JAR Detection (Windows)
      1. Nessus detected 5 installs of Apache Log4j:
        • Path: E:\ProgramData\HP\ALM\webapps\qcbin\WEB-INF\lib\log4j.jar
          • Version: unknown
          • Method: JAR filesystem search
        • Path: E:\Program Files\HP\HP AutoPass License Server\HP AutoPass License Server\HP AutoPass License Server\webapps\AutoPass\WEB-INF\lib\log4j-1.2.15.jar
          • Version: 1.2.15
          • Method: JAR filesystem search
        • Path: E:\Program Files\HP\ALM\ALM\application\20qcbin.war\WEB-INF\lib\log4j.jar
          • Version: unknown
          • Method: JAR filesystem search
        • Path: E:\Program Files\HP\UFT\HP AutoPass License Server\HP AutoPass License Server\webapps\AutoPass\WEB-INF\lib\log4j-1.2.15.jar
          • Version: 1.2.15
          • Method: JAR filesystem search
        • Path: C:\Program Files (x86)\eggplant-alm\lib\log4j-1.2.17.jar
          • Version: 1.2.17
          • Method: JAR filesystem search
  • Mike, lots of people asking this in all manner of places besides here.

    Jerry2 is correct. I've confirmed this with Sprinter through Development and the FT Product Lead. Sprinter is not impacted.

  • log4javascript*js files are not relevant to the log4j vulnerable at all.

  • The hot patch is available here; it may be the best approach for you to resolve this issue because, except for the server restart procedure, it has essentially little impact on all end users. We are attempting to minimize the impact of this vulnerability on your organization.

Related Discussions
Recommended