Log4j2 Zero-Day Vulnerability

There's a new Log4j2 vulnerability in the wild; these are the steps to take to protect yourself...

Hey, all! There's a new zero-day vulnerability hitting the web right now, and it is affecting a lot of libraries and applications out there, including Liferay 7.4.

Any app using Log4j2 is vulnerable. If you are using Log4j2 in your customizations or you are using Liferay 7.4 (which now uses Log4j2), this new vulnerability affects you.

I'm not going to show anything about how to take advantage of the zero-day or verify the exposure as I don't want to give weight to anyone wanting to take advantage of it, but I do want to tell you all how to protect yourselves from it.

You should immediately add the following JVM parameter to your environment:

-Dlog4j2.formatMsgNoLookups=true

In fact, I'd recommend adding this parameter to all of your Liferay environments of any version. This will ensure that if or when you are using log4j2, the vulnerability will be mitigated for you.

44 Comments

Please sign in to comment.

As the entire Java world, yesterday we've also been hastily going through all our systems, looking for this bug :) I think it's worth noting that the only affected Liferay version is 7.4 (and above). All versions below are still using log4j 1.x so they are not vulnerable (confirmed by Liferay support).

Please sign in to reply.

Hi , We are still using Liferay 6.2 which uses Log4j 1.x . is that expose to attack and where its mentioned they are not vulnerable (confirmed by Liferay support).Basically how i can confirm it.

Please sign in to reply.

log4j1 is not susceptible, this was a feature added to log4j2. Some aspects of the updated CVEs on the vulnerability are not exploitable in a standard Liferay configuration as Liferay does not use any of the susceptible patterns.

Please sign in to reply.

Thanks a lot for posting here !!!

Please sign in to reply.

Thanks mate.

Please sign in to reply.

Thanks, changes applied. It would be great to know how a patch from the log4j library can be applied to a Liferay CE release.

Please sign in to reply.

Liferay's working on updated releases with the 2.16 version of log4j2. Should be out soon...

Please sign in to reply.

How far is Liferay from a release? What about log4j2 2.17.1 in the meantime?

```

~/Downloads/liferay-ce-portal-7.4.3.6-ga6 on ☁️ (eu-west-2) ❯ find . -name "*log4j*.jar" ./tomcat-9.0.56/webapps/ROOT/WEB-INF/shielded-container-lib/log4j-1.2-api.jar ./tomcat-9.0.56/webapps/ROOT/WEB-INF/shielded-container-lib/com.liferay.petra.log4j.jar ./tomcat-9.0.56/webapps/ROOT/WEB-INF/shielded-container-lib/log4j-core.jar ./tomcat-9.0.56/webapps/ROOT/WEB-INF/shielded-container-lib/log4j-api.jar ./elasticsearch-sidecar/7.10.2/lib/log4j-api-2.11.1.jar ./elasticsearch-sidecar/7.10.2/lib/log4j-core-2.11.1.jar

```

Please sign in to reply.

The next release is going through build, review and test and should be available soon. It will include the latest version of log4j2.

Please sign in to reply.

Thanks David for this update. In Liferay 7.3.x, in the bundle directory, I found log4j2 jars in directory elasticsearch and in directory state/1639. Are they only used "internaly" to make liferay talk to elasticserach or are they expose "externaly" and a target to a potential attack ? Thank you.

Please sign in to reply.

They are only internal for the Elastic connectors and Sidecar, but they are un-exploitable as they are not exposed and do not log message content.

Please sign in to reply.

Hey David, looks like our 7.2 DXP and elastic search does have version 2.1.1 I checked the properties file and do not see the -Dlog4j2.formatMsgNoLookups parameter. If this parameter is not on the properties file, is the default false? basically do we need to add that parameter if its missing from the properties file.

Please sign in to reply.

This is a JVM parameter. We're using Tomcat so I set it in the <tomcat home>/bin/setenv.sh file.

Please sign in to reply.

Hi David, Can we apply this setting in tomcat/bin/setenv.sh ? -Dlog4j2.formatMsgNoLookups=true

Please sign in to reply.

Yes

Please sign in to reply.

find . -name "log4j*.jar" ./bundles/liferay-ce-portal-7.3.0-ga1/osgi/state/org.eclipse.osgi/1224/18/.cp/lib/log4j-api-2.11.1.jar ./bundles/liferay-ce-portal-7.3.0-ga1/osgi/state/org.eclipse.osgi/1232/18/.cp/lib/log4j-api-2.11.1.jar ./bundles/liferay-ce-portal-7.3.0-ga1/osgi/state/org.eclipse.osgi/78/0/.cp/lib/log4j-api-2.11.2.jar ./bundles/liferay-ce-portal-7.3.0-ga1/osgi/state/org.eclipse.osgi/78/0/.cp/lib/log4j-core-2.11.2.jar ./bundles/liferay-ce-portal-7.3.0-ga1/tomcat-9.0.17/webapps/ROOT/WEB-INF/lib/log4j.jar ./bundles/liferay-ce-portal-7.3.0-ga1/tomcat-9.0.17/webapps/ROOT/WEB-INF/lib/log4j-extras.jar

Ergo: Liferay Portal CE 7.3.0 is affected, apply the mitigation fix as per the Microsoft response to the CVE, immediately!

Please sign in to reply.

Log4j2 is in the Elastic connector and Sidecar, but they are not exploitable. They use internal logging format that does not use the vulnerable log formats, plus they never log message _content_, just general activity.

Please sign in to reply.

Any update on Liferay and Gradle v6.6.1, I tried upgrading Gradle and there is an issue with the plugins:

``` Failed to notify project evaluation listener org/gradle/api/plugins/osgi/OsgiPlugin Failed to notify project evaluation listener osgi/OsgiPlugin ```

Please sign in to reply.

Hi David, is there a remediation plan for Liferay CE 7.2 and above to upgrade log4j2 version to 2.15. in a new Liferay CE release? I see that there is fixed applied to DXP 7.0,7.1,7.2

https://issues.liferay.com/browse/LPE-17068

Please sign in to reply.

I have already added the JVM parameter in Liferay 7.2 servers to mitigate the problem as you recommended

Please sign in to reply.

Liferay will not be issuing new CE releases for older versions of 7 because they don't use log4j2. The only use of log4j2 is in the Elasticsearch connector, and honestly the reported CVEs are not vulnerablities there.

Please sign in to reply.

Hi David, is there a remediation plan for Liferay CE 7.2 and above to upgrade log4j2 version to 2.15. in a new Liferay CE release? I see that there is fixed applied to DXP 7.0,7.1,7.2

https://issues.liferay.com/browse/LPE-1706

I have already added the JVM parameter in Liferay 7.2 servers to mitigate the problem as you recommended

Please sign in to reply.

Liferay is working on releasing updates, should be out soon.

Please sign in to reply.

Thanks David. Apache has released version 2.17.0 of the patch for Log4j after discovering issues with their previous release 2.16. Is liferay working on releasing their updates using apache log4j2 version 2.17?

Please sign in to reply.

The next release of 7.4 will include the latest log4j2.

Please sign in to reply.

According to https://github.com/lunasec-io/lunasec/blob/master/docs/blog/2021-12-14-log4j-zero-day-update-on-CVE-2021-45046.mdx this setting is also not safe...

Please sign in to reply.

Upgrading Liferay 7.4 GA3 to log4j 2.16.0 resulted in being unable to connect to elasticsearch.

Please sign in to reply.

It is not safe generally, but it is enough for a standard Liferay configuration. Liferay doesn't use any of the vulnerable message formats.

Please sign in to reply.

Lunasec has prepared usefull tool (https://github.com/lunasec-io/lunasec/releases/) that looks up hashes of affected classes in a given directory, here is a result of 7.4.3 CE version scan:

└➤ ./temp/log4shell_1.3.0-log4shell_Linux_x86_64 scan liferay/bundles/ 9:39AM ??? Identified vulnerable path cve: CVE-2021-44228 fileName: org/apache/logging/log4j/core/lookup/JndiLookup.class hash: 0f038a1e0aa0aff76d66d1440c88a2b35a3d023ad8b2e3bac8e25a3208499f7e path: liferay/bundles/elasticsearch-sidecar/7.10.2/lib/log4j-core-2.11.1.jar severity: 10.0 versionInfo: "2.10.0, 2.11.0, 2.11.1, 2.11.2, 2.9.0, 2.9.1" 9:39AM ??? Identified vulnerable path cve: CVE-2021-44228 fileName: org/apache/logging/log4j/core/lookup/JndiLookup.class hash: 2b32bfc0556ea59307b9b2fde75b6dfbb5bf4f1d008d1402bc9a2357d8a8c61f path: liferay/bundles/osgi/state/org.eclipse.osgi/204/0/.cp/lib/log4j-core-2.13.3.jar severity: 10.0 versionInfo: "2.13.0, 2.13.1, 2.13.2, 2.13.3" 9:39AM ??? Identified vulnerable path cve: CVE-2021-44228 fileName: org/apache/logging/log4j/core/lookup/JndiLookup.class hash: 84057480ba7da6fb6d9ea50c53a00848315833c1f34bf8f4a47f11a14499ae3f path: liferay/bundles/tomcat-9.0.53/webapps/ROOT/WEB-INF/shielded-container-lib/log4j-core.jar severity: 10.0 versionInfo: "2.14.0, 2.14.1"

Please sign in to reply.

Right, the ES connector and Sidecar currently use log4j2, but they are not exploitable. They use an internal logging format which does not use the vulnerable patterns, plus it never indexes message _content_, only in activity.

Please sign in to reply.

I was guided if it's impossible to replace the log4j jar file, then deleting the JNDILookup.class inside log4j-core-2.xx.jar file will also work.

So I tried following steps to solve log4j vulnerability in my 7.3.2 version.

1. unzip "Liferay CE Foundation - Liferay CE Connector to Elasticsearch 6 - Impl.lpkg" file which is stored in marketplace folder. You will find "com.liferay.portal.search.elasticsearch6.impl-4.0.15.jar" file inside the unzipped folder.

2. unzip "com.liferay.portal.search.elasticsearch6.impl-4.0.15.jar" and locate "log4j-core-2.11.2.jar" file inside the lib folder.

3. unzip "log4j-core-2.11.2.jar" and locate JNDILookup.class file inside the "org/apache/logging/log4j/core/lookup" folder and delete the class file. After deleting it, re-zip the jar files.

4. After zipping "com.liferay.portal.search.elasticsearch6.impl-4.0.15.jar" rename it to "com.liferay.portal.search.elasticsearch6.impl.jar" and copy the file to [Liferay_HOME]/osgi/marketplace/override folder.

5. restart Liferay, and the overridden jar file will be installed during startup.

I haven't found any functional errors yet after replacing the file.

Give it a try and let me know :)

Please sign in to reply.

So Liferay is working on an update so this activity may not be necessary if you can wait.

Additionally, since the connector and Sidecar use internal logging configuration (which do not use the vulnerable patterns) and never log message content, only activity, the log4j2 there is not exploitable.

It can be hard to convince folks this from a standard tool scan, but it is what it is.

Please sign in to reply.

Hi David, is there an excpected date for the liferay patch ? and Will it be compatible also with Liferay 7.2.1 ? or you are working on a patch on the latest version only ?

Thanks

Please sign in to reply.

Hi David,

Thank you for your explanation on log4j2 been not exploitable.

Despite this, we have implemented the mitigation measures to be safe.

Yes, we are having a pretty hard time trying convincing our users the same, even when this post is shared. They want to know

1) Whether your explanation is a representative view of Liferay. (We meant no disrespect)

2) When are we looking to have a patched version?

Are you able to shine some light on the above?

Please sign in to reply.

I tested it and it works :) ! Thanks .

Waiting for the official patch though

Please sign in to reply.

Hello everybody

We're using 7.2.1, that includes log4j 1.2.17. There is a similar vulnerability that affects this version: https://www.cvedetails.com/cve/CVE-2021-4104/

What should we do? Does the suggested workaround work? Do we have to upgrade to a specific Liferay version? Can we substitute the lib?

Thanks in advance for your help

Please sign in to reply.

After reviewing the CVE Liferay determined that it is not vulnerable to the issue reported there. There is (AFAIK) no plans for Apache to issue an update for 1.2, so there's not much that you can or should do about the CVE.

Please sign in to reply.

Thanks for your kind answer

Is advisable to upgrade to coming soon Liferay 7.4?

Thanks in advance

Please sign in to reply.

I think it is good to upgrade in order to take advantage of new features and functionality, but you'd need to evaluate on your own. Since there is a cost involved (in time, money and resources) you should weigh that against how important it is to be off of log4j1.

Please sign in to reply.

And what about https://www.cvedetails.com/cve/CVE-2019-17571/ ?

Please sign in to reply.

Liferay does not use the socket support at all in its logging configuration, so it is deemed not exploitable.

Please sign in to reply.

Hello.

Will there be a release which includes a newer version of elasticsearch? Customers are permanently asking because their security scanners report the log4j-jars in the elasticsearch sidecar.

Please sign in to reply.

Yes, those releases are all out for CE and DXP 7.4. For DXP 7.3 and earlier, updates are also available.

Please sign in to reply.

As far as I can see in version 7.4.3.15-ga15 it is still elasticsearch 7.10.2. Which still contains log4j-2.11.1 and our customer is urging us to upgrade the version to 7.16.3 which contains log4j-2.17.1.

Will ther be a future version with elasticsearch 7.16.3 released from your side? Or if it already exists and I just can't find them could you so nice and provide me the link to this version?

Please excuse the circumstances and thank you in advance.

Please sign in to reply.

Menu Display

Blogs

Category Filter

Log4j2 Zero-Day Vulnerability

There's a new Log4j2 vulnerability in the wild; these are the steps to take to protect yourself...

More Blog Entries

Office Hours

Liferay SSO - Step by Step