A new Flexera Community experience is coming on November 18th, click here for more information.
A critical vulnerability in Apache Log4j 2 impacting versions 2.0-beta9 through 2.12.1 and versions 2.13.0 through 2.14.1 has been publicly disclosed. The vulnerability has been assigned the identifier CVE-2021-44228.
Cognos has been identified as potentially being affected by CVE-2021-44228. IBM’s Cognos is included in Flexera Analytics and is used as a reporting engine for FlexNet Manager Suite and FlexNet Manager for Engineering Applications. This article describes possible mitigation steps that can be applied to Cognos, as used in Flexera Analytics, until a formal hotfix is issued.
Affected users should do one of the following:
or
IBM has published general guidance and remediation options at the following location: An update on the Apache Log4j 2.x vulnerabilities.
To remove the JndiLookup class on an installation of Flexera Analytics (Cognos):
1. Make a backup copy of log4j-core-2.7.jar found here (where "<number>" is a number that depends on the Cognos version installed): C:\Program Files\ibm\cognos\analytics\wlp\usr\servers\dataset-service\workarea\org.eclipse.osgi\<number>\0\.cp
2. Copy the same log4j-core-2.7.jar file to a directory you have write access to.
3. Open the copy of log4j-core-2.7.jar in a program like 7Zip.
4. Delete the file JndiLookup.class.
5. Save the updated .jar file archive.
6. Copy the updated log4j-core-2.7.jar file back to the original location: C:\Program Files\ibm\cognos\analytics\wlp\usr\servers\dataset-service\workarea\org.eclipse.osgi\<version>\0\.cp
7. Also replace the file in this location: C:\Program Files\ibm\cognos\analytics\wlp\usr\servers\cognosserver\workarea\org.eclipse.osgi\<version>\0\.cp
To uninstall Cognos, uninstall the IBM Cognos Analytics application through the Windows Add Remove Programs applet:
Note: This will result in all Flexera Analytics functions being unavailable to users. |
2021-12-15 9:00am CST: Initial article.
2021-12-15 7:20pm CST: Update details to allow for directory names which may vary based on the version of Cognos.
on Dec 15, 2021 08:58 AM - edited on Jul 18, 2022 12:11 PM by HollyM
@AustinG Thanks for the detailed instructions. In my installation the paths to the log4j-core-2.7.jar file are a bit different. Instead of 106 and 117 as illustrated above, we have 102 and 113. Assuming I should remove the class file from the jar in those directories?
Thanks!
@DiannaB The path you see above was created based on the latest versions we have. If the class files in those other paths match exactly as shown above, then they should be removed.
Also found that file in 102 as well.
C:\Program Files\ibm\cognos\analytics\wlp\usr\servers\cognosserver\workarea\org.eclipse.osgi\102\0\.cp
1 clarification – on the mitigation step: We only have to do 1 of the following, else the 2nd option would require uninstallation of Flexera Analytics (Cognos)
Program/ software from the server itself, which renders the reporting engine invalid.
Affected users should do one of the following:
1. Follow IBM remediation options.
Removal of JndiLookup Class,
From: https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/
2. Remove Flexera Analytics (Cognos) from the computer where it is installed.
@sohbinong - correct: either remove the JndiLookup class, or remove Flexera Analytics (Cognos). It doesn't make sense to attempt both mitigation steps.
Thanks @ChrisG
The bulletin is out from IBM on Cognos Analytics.
https://www.ibm.com/blogs/psirt/security-bulletin-ibm-cognos-analytics-apache-log4j-vulnerability-cve-2021-44228/
Can please advise what is the Eventual Patching for Cognos 11.x and the timeline this will be fixed for FNMS on-premises. Thanks.
Awesome - great find @sohbinong. Thanks for sharing that link! I'll make sure the Flexera technical teams are aware of this, and look to ensure this page and the CVE-2021-44228 summary page are updated with any information about patching possibilities as it becomes available.
Thanks @ChrisG
Hello,
in the IBM KB Security Bulletin: IBM Cognos Analytics: Apache log4j Vulnerability (CVE-2021-44228) is now a list of fixes where I see a fix for IBM Cognos Analytics which is used by the Flexera FNMS: Cognos Analytics 11.0.13 Interim Fix 3.
Can we get an estimate when the hotfix will be released by Flexera for the Flexera Analytics?
Thank you!
Best regards,
Pavol
Hello,
FYI, Apache released information that the 2.16 was still vulnerable here and also release version 2.17.
So I assume the "Removal of JndiLookup Class" didn't fix the issue. IBM didn't update the instructions for this on their web, so also their fixed installation packages will probably have the 2.16 libraries which are vulnerable. Please be cautious.
In my environment I have stopped and disabled the IBM Cognos service on the Analytics server and deleted the log4j-core.jar files in both locations. FNMS is still working without this part without any issues.
Regards,
Pavol
@pavol_holes - no timeframe has been announced yet for when Flexera Analytics with the updated Cognos release from IBM will be available, but Flexera's technical teams are actively investigating it. Keep watching this article here for updates.
I have not seen any information that suggests the Log4j 2.16 version is still vulnerable to CVE-2021-44228 (i.e. the vulnerability which may allow remote execution). Everything I've seen suggests that vulnerability is still safely mitigated by either of the steps described in this article (i.e. turning off the software, or removing the JndiLookup class). Have you seen anything that suggests otherwise?
From the page you linked I understand that the 2.17 version of Log4j addresses another vulnerability (CVE-2021-45105). If exploited, this vulnerability may result in a DOS (Denial of Service) attack. For the use of Flexera Analytics and Cognos in the context of FlexNet Manager Suite or FlexNet Manager for Engineering Applications running an internal corporate environment where it typically has a relatively small number of users for purposes that are not business critical, this would be unlikely to be material concern.
@ChrisG / @AustinG ,
I found the log4j-core-2.7.jar at two locations :
D:\Program Files\ibm\cognos\analytics\wlp\usr\servers\dataset-service\workarea\org.eclipse.osgi\102\0\.cp
D:\ProgramFiles\ibm\cognos\analytics\wlp\usr\servers\cognosserver\workarea\org.eclipse.osgi\113\0\.cp
All I need to update this log4j-core-2.7.jar only at the two locations as per the steps given, should I be worried about other log4j jar files (such as log4j-api-2.7.jar, log4j-web-2.7.jar, etc)
@brian_lentini
Thanks,
Sushant
@sushant_narula - the CVE-2021-44228 vulnerability is related to code that is typically in the log4j-core-*.jar file. You don't need to worry about the other files that you're finding on the Cognos system there; based on the information on the page at https://logging.apache.org/log4j/2.x/security.html I understand those files don't contain the code with the vulnerability.
@ChrisG there is mitigation provided by IBM for the users using cognos
https://www.ibm.com/support/pages/node/6526474
when we try to access this page there is a link within this page "To get the patch and detailed instructions, click this link" and it's asking for access. As per my understanding when we install Cognos I was told there are no separate licenses that are required as Cognos licenses are included as part of the analytics module, so what should we now check with IBM. please assist
@raghuvaran_ram - if you have a standalone installation of Cognos then downloading a patch from IBM as per the information you've found from IBM may be an appropriate path forward. However for the Cognos modules that are included in the Flexera Analytics component that is part of FlexNet Manager Suite and FlexNet Manager for Engineering Applications, Flexera's current recommendations are reflected in the guidance contained within in this article here.
In the "IBM's recommendations to it clients" section of this, bullet item 2 refers to "Implement latest patch to production environments as soon as possible". When attempting to access the IBM site to get the patch we are being prompted for a login. Is there somewhere else we can get it?
Check out this link here from IBM: To get the patch and detailed instructions, click this link: log4jSafeAgent
@jrobs3 - Flexera is working with IBM to look at getting an updated version of Cognos that will work with Flexera Analytics, and this article will be updated with details in due course.
In the meantime, the mitigation steps described in this article to either remove the vulnerable JndiLookup class from systems (I would expect this is going to typically be the preferred option) or uninstall Cognos are recommended.
As per the recommendation the JndiLookup class was removed from log4j-core-2.7.jar earlier this month and I am seeing the class file now showing up in the jar file again. Has anyone else observed the same? Will cognos work if the log4j-core-*.jar file is completely removed?
@devi_g - I haven't heard of the .jar file magically being reverted. If you remove the class again, does it come back again?
I don't know, but suspect that Cognos would struggle if the .jar file is deleted off the filesystem entirely. If you want to try that I would proceed cautiously. (I expect it would be easy enough to revert by replacing the file back again if it does cause problems.)
Hi @ChrisG, that is correct. I followed the steps to remove the file as above (Removal of JndiLookup Class), the JndiLookup.class comes back again in the log4j-core-2.7.jar once Cognos restarts. I am observing this with both FNMEA and FNMS. I've opened a ticket with Support to look into this.
Hi @devi_g we are have the same situation as you. JndiLookup.class comes back again in the log4j-core-2.7.jar
Did you have an answer from your support case ?
Hi Chris,
We have noticed at my customer that the article is missing some JndiLookup class files.
The thirtpartycertificateTool.jar also contains the JndiLookup class files.
Can you please extend the article? And confirm that it will be included in the fixed?
@Ronny_OO7 - thanks for noting that. I've passed this on to the appropriate engineers to consider whether this represents a potential exposure to any vulnerabilities.
@ChrisG Your welcome and thank you for your help!