Blogs

Blogs

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.

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).

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.

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.

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

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

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

```

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.

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.

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!

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.

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 ```

 

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

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.

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

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

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"

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.

Hi 

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 :)  

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.

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?

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

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.

Thanks for your kind answer

Is advisable to upgrade to coming soon Liferay 7.4?

Thanks in advance

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.