Apache Log4j Security Vulnerability

[Techie]

Hi All,

Does anyone know if Drools uses Log4j internally which has the Day-Zero security vulnerability

Log4j – Apache Log4j Security Vulnerabilities

Thanks

[Matteo Mortari]

Hi,

Drools (https://github.com/kiegroup/drools) internally have been using SLF4J (http://www.slf4j.org) for a long time, so to answer your question, no.

Only some examples might have been using Log4j as a logging backend, but still from SLF4J; so unless you import and use the Log4j API in *your* application code that again is not impacting.

Please avoid cross-posting, I've seen this message both on drools-usage and drools-development mailing-list. Ref: https://drools.org/community/getHelp.html

Hope this helps,

MM

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/82615311-9210-4cca-b1b5-02b800cb720cn%40googlegroups.com.

--

Matteo Mortari

linkedin.com/in/matteomortari

youtube.com/MatteoMortari

[Techie]

I am actually using JBPM install for the Rule Engine, and you are correct it uses SLF4J (see the following list)
./jbpm/standalone/tmp/vfs/temp/tempe9e630c629daac9f/content-1c42d20eaab11138/WEB-INF/lib/log4j-over-slf4j-1.7.30.jar
./jbpm/standalone/tmp/vfs/temp/tempe9e630c629daac9f/content-fbf85807027a13c8/WEB-INF/lib/log4j-to-slf4j-2.13.2.jar
./jbpm/standalone/tmp/vfs/temp/tempe9e630c629daac9f/content-fbf85807027a13c8/WEB-INF/lib/log4j-api-2.13.2.jar
./jbpm/standalone/tmp/vfs/temp/tempe9e630c629daac9f/content-fbf85807027a13c8/WEB-INF/lib/log4j-over-slf4j-1.7.30.jar
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-over-slf4j-1.7.30.jar-e4e7845da9666799
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-over-slf4j-1.7.30.jar-e4e7845da9666799/log4j-over-slf4j-1.7.30.jar
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-over-slf4j-1.7.30.jar-e4e7845da9666799/contents
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-to-slf4j-2.13.2.jar-c8e97a4d3ae038fc
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-to-slf4j-2.13.2.jar-c8e97a4d3ae038fc/log4j-to-slf4j-2.13.2.jar
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-to-slf4j-2.13.2.jar-c8e97a4d3ae038fc/contents
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-api-2.13.2.jar-e13b1637eeb88ef1
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-api-2.13.2.jar-e13b1637eeb88ef1/log4j-api-2.13.2.jar
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-api-2.13.2.jar-e13b1637eeb88ef1/contents
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-over-slf4j-1.7.30.jar-55c2fc82e525c2fe
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-over-slf4j-1.7.30.jar-55c2fc82e525c2fe/log4j-over-slf4j-1.7.30.jar
./jbpm/standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-over-slf4j-1.7.30.jar-55c2fc82e525c2fe/contents

Are we sure this one does not have the Day-zero security vulnerability?

[Matteo Mortari]

Hi Techie,

> I am actually using JBPM install for the Rule Engine, and you are correct it uses SLF4J (see the following list)

My answer limited specifically to Drools, not something else.

> Are we sure this one does not have the Day-zero security vulnerability?

This is a SLF4J question; we're monitoring the situation and we are following the SLF4J feedback, you can find more details here: http://slf4j.org/log4shell.html

If you have SLF4J specific questions or concerns, the appropriate place is the SLF4J team.

In general, I suggest you periodically check with the KIE blog as if we will report any additional findings, for Drools or any other KIE related project such as jBPM, etc, we're likely going to push them there: https://blog.kie.org

Hope this helps,

MM

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/4cc57fb4-dabc-49a3-960a-e36f3c7d6477n%40googlegroups.com.

[Techie]

Hi Matteo,

The security scan shows the following as vulnerability

./standalone/tmp/vfs/deployment/deployment25b1558ccb2d397f/log4j-api-2.13.2.jar-37b09b08778a1cc3/log4j-api-2.13.2.jar

Any idea on where the xml / pom file for this would be, which is using this jar

[Matteo Mortari]

Hi Techie,

> ./standalone/tmp/vfs/deployment/deployment25b1558ccb2d397f/log4j-api-2.13.2.jar-37b09b08778a1cc3/log4j-api-2.13.2.jar

> Any idea on where the xml / pom file for this would be, which is using this jar

That, I assume, is your KIE Workbench/Business Central local installation operating (eg: a running Business Central inside of your local Wildfly server).

That could be very likely be due to the AppFormer DashBuilder declared dependency, more details in the blog post just out: https://blog.kie.org/2021/12/kie-log4j2-exploit-cve-2021-44228.html

Alternatively, it could be a declared dependency in your project, in that case you might want to double check your KIE project pom.xml dependencies or your application pom.xml dependencies.

We invite you to keep monitoring the blog post, in the case there might be in the future any further findings.

=> https://blog.kie.org/2021/12/kie-log4j2-exploit-cve-2021-44228.html

Hope this helps!

MM

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/aa21ac83-0099-4723-a2c4-2a5e3506ccbfn%40googlegroups.com.

[Melat Hadgu]

Hi, I  have the same issue with  above,  I am using business central 7.45 deployed on wildfly 19 and the following directory  resulted in Log4Shell”, CVE-2021-44228
 vulnerability.

./standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-over-slf4j-1.7.30.jar-e4e7845da9666799

1. what is the effect of deleting this directory on the business central application?

2. Is the latest  business central war file(7.62.0 final) free from the log4j vulnerability?

[Toshiya Kobayashi]

Hi,

> ./standalone/tmp/vfs/deployment/deploymentd95d18d8ff3fa18b/log4j-over-slf4j-1.7.30.jar-e4e7845da9666799

Firstly, the vulnerable module is log4j-core, not log4j-over-slf4j. But anyway, business-central 7.45.0 contains log4j-core so it's a problem.

> 1. what is the effect of deleting this directory on the business central application?

standalone/tmp/vfs directory is a temporary working directory of wildfly. Actulal jars exist in standalone/deployments/business-central.war. So deleting the standalone/tmp/vfs directory wouldn't help (and it may just break runtime execution).

> 2. Is the latest  business central war file(7.62.0 final) free from the log4j vulnerability?

Yes. Please upgrade.

For detailed information, please refer to https://blog.kie.org/2021/12/kie-log4j2-exploit-cve-2021-44228.html

Regards,
Toshiya

2021年12月22日水曜日 3:50:27 UTC+9 hadgu...@gmail.com: