[NOTICE] Critical Vulnerability in Log4j2

Ryan Carrie shared this announcement 54 days ago

Remote Code Execution in Log4j [CVE-2021-44228]



Update January 10, 09:12 AEST: Yellowfin is aware of existing CVE's against log4j 2.16(CVE-2021-45105 & CVE-2021-44832). Yellowfin's default logging configuration is not vulnerable to either without modification to the log4j2.xml file. The log4j library will be upgraded in a future release, TBD.

Update December 21, 12:00 AEST: Patched versions 8.0.10.4, 9.4.2.1, 9.5.1.1 and 9.6.2.1 have now been added to the Docker page. Text in the post below has been updated to reflect this.

Update December 20, 19:40 AEST: Yellowfin is aware of the newly discovered vulnerability in log4j, per CVE-2021-45105. Initial review of this vulnerability indicates that Yellowfin log4j2 configurations do not include the vulnerable lookup type. Testing is ongoing to determine whether this can be exploited against Yellowfin in spite of this consideration.

This vulnerability has been graded lower than previously reported vulnerabilities below and at present there are no plans to publish an emergency patch. We will continue to monitor the situation, and this vulnerability will be considered for a future patch release. 

Update December 17, 15:56 AEST: Patches for versions 9.6, 9.5, and 9.4 are now available. Please see section ‘Remediation Option 1’ below for links. We are currently working on patched releases for older impacted versions of 8, which will also be added here.

Update December 15, 20:21 AEST: Patches for Yellowfin versions 9.7 and 8.0.10 to mitigate exposure are now available. These patches use the updated log4j2.16 library. Please see the post below for updated links and remediation advice. We highly recommend that you use the patches, but if this is not possible,use one of the other (new) remediation options.

We are currently working on patched releases for earlier versions, which will be added below once available. Further updates to follow.

Update December 15, 14:34 AEST: Additional information has come to light showing that log4j2.15 is also exploitable. We are currently in the process of patching the latest YF releases with the updated log4j2.16 library. Further updates to follow.

Update December 14, 16:45 AEST: Ongoing testing has revealed scenarios in which Yellowfin software is vulnerable to the log4j vulnerability. The remediation steps below should be implemented as soon as possible.

Log4j 2.x in versions earlier than 2.16.0 are affected by a critical vulnerability that can lead to remote code execution (RCE) in some circumstances. This does not affect Yellowfin software in releases prior to December 2020, but does affect more recent releases. Affected Releases;

9 series : 9.4.0 or later

8 series : 8.0.8 or later

v7 and v6 releases are not affected unless you have manually upgraded to Log4j2.

The following information is provided to all our customers regardless of their setup. Due to the severity of this vulnerability, we highly recommend you apply the patched version of Yellowfin, or one of the other two remediation options, to fully protect your systems

Vulnerability details

From the official CVE:

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP Servers when message lookup substitution is enabled.

Yellowfin versions 8.0.8 to 8.0.10.1, and Yellowfin 9.4 to 9.7 ship with log4j 2.13.3, which is affected. 


Remediation option 1: install the patch

We have released a patch for Yellowfin 8 and 9 that uses an unaffected version of log4j (log4j2 2.16.0).

Version 9.7.0.3

Version 9.6.2.1

Version 9.4.2.1

Version 9.5.1.1

Version 8.0.10.4

Yellowfin Docker: Images updated to 9.7.0.3, 8.0.10.4, 9.4.2.1, 9.5.1.1 and 9.6.2.1: https://hub.docker.com/r/yellowfinbi/yellowfin-app-only


Remediation option 2: upgrade log4j in an existing Yellowfin instance

It is possible to upgrade log4j in Yellowfin independently of a patch. Download log4j 2.17.0 binary distribution from the log4j website. This remediation option will work on all versions of Yellowfin that are affected by the vulnerability.

From the distribution zip file, extract the following files and copy them into the Yellowfin/appserver/webapps/ROOT/WEB-INF/lib folder:

log4j-1.2-api-2.17.0.jar

log4j-api-2.17.0.jar

log4j-core-2.17.0.jar

log4j-web-2.17.0.jar

You will also need to remove the existing log4j libraries in the folder. These files will have the same names, but with a different version number. Either version 2.13.3 or 2.15.0. If you do not remove the existing files, the system may not start, or could still be vulnerable to the exploit.

After replacing the log4j libraries, restart Yellowfin.

Upgrading Yellowfin’s log4j libraries independently of a Yellowfin patch may break future upgrades. When performing an upgrade, it may be necessary to revert to the old libraries prior to the upgrade. (The upgrade would then deliver a new version of log4j as part of the upgrade process).


Remediation Option 3 - Remove the JNDI handler class from log4j.

It is possible to remove the internal code that causes the vulnerability from the vulnerable version of log4j. This internal code is present in JndiLookup.class in the log4j-core-2.13.3.jar file.

Run this command from the classpath to remove the code from the library: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Once the class is removed from the library, restart Yellowfin for the changes to take effect.


We recommend you perform one of the remediation options immediately for protection against this vulnerability.

Best Answer
photo

Please be aware comments are not monitored by the support team. For any Yellowfin Support related queries, please reach out to the support team via a ticket or public post.

Comments (11)

photo
2

This seems to not be the instructions for when YF is run as a windows service? Please provide the instructions to apply this when running a windows service as soon as possible.

photo
1

Hi Mike,

Thanks for pointing that out! We've updated the announcement to include this information. Please don't hesitate to open a ticket if you have any trouble.

Regards,

Ryan

photo
photo
1

Hi Yellowfin Team,


which version of Log4j is used in the version 7.4.5?


Regards,

Veronika

photo
1

Hi Veronika,

I can confirm that versions of 7.4 and earlier are using the log4j 1.x version, which is not impacted by this listing.

Regards,

Ryan

photo
1

Are you certain that 1.x versions of log4j are not impacted?

  • Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.

https://logging.apache.org/log4j/2.x/security.html

  • Log4j version 1.x is not directly vulnerable, because it does not offer a JNDI look up mechanism. However, Log4j 1.x comes with JMSAppender, which will perform a JNDI lookup if enabled in Log4j's configuration file (i.e., log4j.properties or log4j.xml). Thus, an attacker who can write to an application's Log4j configuration file can perform a remote code execution attack whenever Log4j 1.x reads its malicious configuration file.

https://www.technology.pitt.edu/content/additional-guidance-regarding-log4j-vulnerability

photo
photo
1

Are you able to confirm at this time if the logon page is vulnerable to any unauthenticated attacks?

photo
1

Hi Chris,


Yellowfin is not aware of any viable, unauthenticated attacks against the login page. Please don't hesitate to reach out with any questions or concerns via private ticket or through email: security@yellowfin.bi.

Regards,

Ryan

photo
photo
2

So just to be clear...

  1. You initially thought Yellowfin was vulnerable
  2. You've since realised that, when using the default configuration, Yellowfin is not vulnerable
  3. You're still advising admins to patch / upgrade to mitigate due to the severity of the vulnerability

photo
1

Hi Tormod,


Apologies for the confusion, the situation is still evolving, as of right now we are vulnerable, and it seems log4j has been patched again as vulnerabilities were found in 2.15, we're currently working on another update as we speak.


Thanks,David

photo
photo
1

@Ryan

Please suggest steps for yellowfin running on Docker ,we are running yellowfin on docker with 9.5 version, do we need to build image again ?

Please publish patch or required steps for fix


Regards

photo
1

    && unzip yellowfin-9.6.2-20211028-full.jar yfres/yellowfin.zip \
    && unzip yfres/yellowfin.zip appserver/bin/catalina.sh \
    && sed \
         -e '1 i\JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"' \
         -i 'appserver/bin/catalina.sh' \
    && zip yfres/yellowfin.zip appserver/bin/catalina.sh \
    && zip yellowfin-9.6.2-20211028-full.jar yfres/yellowfin.zip \

@Ravi, you might try something like the above. sounds like there'll be another mitigation to be applied for the second cve though

photo
photo
1

Hi we have Yellowfin 8.0.2 running with log4j-1.2.17.jar. Will the latest patch be ok to apply as it references 8.0.1 ?

photo
1

Hi Michael,


log4j is not affected by the above listing. 8.0.8 releases and later ship with log4j2. We have provided patches for 8.0.10 (not 8.0.1 as it's not required).


Hope this clears up any confusion.


Thanks,

David

photo
photo
1

Hi, will you be releasing an update using version 2.16 to address CVE-2021-45046? 2.15 is still susceptible attack

https://www.cve.org/CVERecord?id=CVE-2021-45046

photo
1

Please be aware comments are not monitored by the support team. For any Yellowfin Support related queries, please reach out to the support team via a ticket or public post.

photo
2

The previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

photo
2

Hello,

You've removed the previous guidance to set the following configuration

-Dlog4j2.formatMsgNoLookups=true"

Is that still a valid remediation strategy?

photo
1

can find the other two, which download contains this JAR? log4j-core-2.16.0.jarlog4j-web-2.16.0.jar

used this URL: https://dlcdn.apache.org/logging/log4j/2.16.0/apache-log4j-2.16.0-bin.zip

photo
1

nevermind - please delete

photo
1

I thought the same thing at first. These two files are actually separate. (log4j-core-2.16.0.jarlog4j-web-2.16.0.jar). It was just a typo when trying to get the fix out to us quickly. They should have been separated by a space or on a separate line. All files are in the zip and in the tar.gz.

Like this...

log4j-1.2-api-2.16.0.jar

log4j-api-2.16.0.jar

log4j-core-2.16.0.jar

log4j-web-2.16.0.jar

photo
1

Hi ,

we have upgraded our yellowfin to yellowfin:9.7.0.3 Docker Image. Please let us know or way to validate log4j upgrade is completed properly

photo