UPDATE: Revenera’s response to Apache Log4j vulnerabilities CVE-2021-45105, CVE-2021-45046, CVE-2021-44228, and CVE-2021-4104
(as of 14-Jan 10:20 CST)
A critical vulnerability in Apache Log4j 2 impacting versions from 2.0-beta9 to 2.14.1 has been publicly disclosed. The vulnerability has been assigned the identifier CVE-2021-44228.
Revenera is expanding its product impact assessment and mitigation information to include CVE-2021-45105, CVE-2021-45046, CVE-2021-44228, and CVE-2021-4104. This notice provides currently available information about the potential impact of these vulnerabilities on Revenera products.
NOTE: Be advised this is an ongoing assessment. Information about related and subsequent Log4j CVEs not listed below may be found in the product's respective knowledge base.
As you may be aware, a vulnerability was discovered in the Log4j Java library, potentially allowing attackers to take control of systems and execute malicious commands. For more detailed information about the vulnerability, please see the following resources:
Revenera is actively working with our product teams to review Software Composition Analysis scans of our products to determine the impact, if any, on our solutions. We appreciate your patience and understanding, and we will provide an update once more information about affected products and remediation plans are confirmed.
Our current mitigation strategy for this has been to put a complete block on ALL outgoing network access from our FNO server, with a specific exemption for SMTP access to our mail server. So, no http to google, no ntp, etc.
Given that this is a single-purpose server, are there any other outgoing connections that an FNO server might need to have whitelisted?
@maxhenselnonse: To me this looks like version 1.2.17 is used for the FNE LLS. But according to the CVE only versions from 2.0 to 2.14.1 are affected? Can someone confirm this?
Hi all, When I check our Code Insight installation I see log4j-core 2.11.1 in the tomcat directory (/tomcat/webapps/codeaware/WEB-INF/lib/log4j-core-2.11.1.jar) so I would presume it's used in our installation. Is there a good and advised way to mitigate this?
We also need an update from Revenera on Code Insight (both 6.x and 7.x versions), as we need to respond to IT and Cyber Security inquiries on these applications.
Thank you everyone for your patience as we assess the impact and remediation plan for this vulnerability as it relates to the Code Insight product. One piece of information that we were able to confirm is that the following Code Insight v6 configurations are definitely not impacted:
1. Code Insight v6 instances that are used for Workflow only, without scanning.
2. Code Insight v6 instances that are configured to scan using Analyzer instead of CodeAware.
If you have one of these configurations in your environment, remediation is not necessary. Note: other configurations are also potentially not impacted, but we are waiting for confirmation from Engineering to be able to tell you for sure.
@madhug - InstallShield 2016 SP2, InstallShield 2018, and InstallAnywhere 2018 have included an additional module - Codeaware to scan for Open Source components included in your project. This is a separate menu item in Project menu (for InstallShield) or Build menu (for InstallAnywhere) which invokes a wizard for scanning. This module has to be explicitly invoked and is not automatically invoked during launch of InstallShield/InstallAnywhere or building projects using IDE or Standalone Build.
I see certain product here are mentioned with an attached version, Flexnet Publisher for example. 11.18.3.0 is stated here, shall we regard only this specific version potentially affected? Shall we regard all 11.18 versions affected for example?
We use InstallAnywhere 2020 Build 6318 to package our software for installation on Windows and Linux. Can you confirm that any installer packages generated with this will not contain the log4j issue please?
Hi @pierre_olsson for FNP, all the versions are affected however the issue is fixed for 11.8.3.0 and we have already released 11.18.3.1 in the PLC. For older versions of FNP other than 11.8.3.0, customers can update the log4J to the latest version which is like 2.15 or 2.16.
Is there any sort of update on when we can expect a patch for FlexNet Operations On-Premises? We have had to take this server offline and it is affecting our ability for customers to activate their licenses.
@mkulvietis - the KB article mentions "Set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true" - have you done that? I'm not sure if that's done in the System variables for Windows or if that is set on the command line for running FNO.
Did you replace all instances of the 2.8.2 file with a 2.16 file, or just their contents? (ie, did your filenames remain the same? And did you need to do Oracle as well, or are you running a different database (or against a remote instance)
At this point in time, I'm still leaning towards the "remove the JndiLookup.class from any .jar I find it in" approach
Initially we did the "remove the JndiLookup.class" fix and another fix but figured out how to replace the log4j files. There were 4 and we tested it last night and all seems to be well. We're running MS SQLServer.
We've done this to a test server and tomorrow am I'll write this up and we want to do the production server tomorrow, we've disabled internet access to it and it's been unavailable to our customers for a week now. I'll post the write-up as soon as I'm finished.
Did you do a full re-deploy of the software, or just hit all the .jar files in-situ?
We only blocked outgoing connections from our license server so incoming activation requests still work fine - our customers should not be affected. Since the exploits all rely on external access, this seemed like a reasonable compromise - the only port we needed to open was SMTP which is still locked to a fixed server that we control.
I have removed JndiLookup.class from all log4j-core files and it seems a good solution so far. But now I wonder if Flexnet Operations is vulnerable to new CVE-2021-45105.
It seems that FNO is not using Context Lookup (like ${ctx:loginId}) in log4j configuration by default and so it should not be vulnerable, but I'm no log4j expert, perhaps Flexera knows better.
Use at your own risk, this is what we tested over the weekend but now we'll have to test with 2.17. I looked at removing outbound internet access but we have this server at AWS and didn't want to break communications with any of their stuff.
We were at version 2.8.2 of log4j. For any paths below I'm referring to Log4j locations on my FNO 2018 R1 Windows server. I'd search your server for where they may be squirreled away. On Windows I love using AgentRansack for searches.
Stop FlexNet services, apply the updates, and reboot.
** Removing JndiLookup.class from the classpath: **
$ zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
For this I used 7-Zip to open all the log4j-cor*.jar files mentioned above , navigated to org/apache/logging/log4j/core/lookup and deleted JndiLookup.class
Is it possible to get an update on the usage intelligence SDK please. My own examination of the jar file that is incorporated into products suggests it does contain Log4j 2.x, but it looks like a stripped down version that doesn't include Jndi functionality and so may not be vulnerable to these issues.
In keeping with the guidance of our security team, we are working on upgrading to the latest recommended Log4j version (2.17.0). Subject to any issues during testing, we plan to have this available by the end of next week.
Hi @pauli_tuominen Thanks for the information about CVE-2021-44832 new vulnerability, let me check for more details and come back as soon as possible about the impact of this CVE-2021-44832.
Update: 31/Dec/2021: FNO Onprem 2021.R1 Log4j version has been upgraded to 2.17.0 and 2021_R1_HotFix_log4j_Upgrade_2.17_and_SWM-9817.zip is now available in the Product and License Center. Note: The same will be updated in the document soon.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
