Wildfly and CVE-2021-44228

[Mike Douglass]

Is there any official statement on wildfly as regards this vulnerability?

As far as I can tell there is no vulnerability as long as applications don't deploy and use log4j directly.

My deployments only contain the log4j-slf4j adaptor and as far as I can tell no log4j code is present.

[Boris Unckel]

There is an official statement here: https://twitter.com/WildFlyAS/status/1469362190536818688

[Anand Victor]

We use wildfly-24.x in our environment.

When i checked the dependencies in wildfly-24.x - From here wildfly-24.x uses wildflycore-16.x and wildflycore-16.x (here) uses log4j - 2.14.1 

log2.14.1 is vulnerable.

I see efforts to fix the latest version wildfly-26.x ( jira )

I am really not sure since there is no official statement yet.

Thanks

Anand Victor

[Steven Wright]

Does this statement cover ALL versions, or only after a specific release?

[Jens Pelzetter]

In the statement from Wildfly they say that you should upgrade as soon as possible. But at least for me it looks like the log4j-api-2.14.1.jar bundled with Wildfly 25.0.1.Final causes  a problem when deploying an application with log4j-core-2.15.0 and log4j-api-2.15.0. The deployment fails with the error java.lang.NoSuchFieldError: EMPTY_BYTE_ARRAY. The problem is that this field was moved in log4j-2.15.0 to another location. Any idea how to solve this? Can I replace the log4j-api-2.14.1.jar in Wildfly 25.0.1.Final with log4j-api-2.15.0 or do I have to wait for an update?

Best

Jens

[Boris Unckel]

It covers all versions. log4j-core (NOT the log4j-api) is affected. Only log4j-api is shipped with wildfly.

kama...@gmail.com schrieb am Montag, 13. Dezember 2021 um 16:22:50 UTC+1:

[Boris Unckel]

log4j-core (NOT the log4j-api) is affected. Only log4j-api is shipped with wildfly. There is an official statement here: https://twitter.com/WildFlyAS/status/1469362190536818688

[Boris Unckel]

You have to remove the logging subsystem with a jboss-deployment-structure.xml file. My recommendation is to choose either to remove *all* logging libraries (including sl4j, commons-logging, spring-jcl, log4j-api, log4j-core, jboss-logging) from your deplyoment (EAR/WAR/RAR) or to remove the logging subsystem. Mixing both is a mess.

[James Perkins]

Hi Jens,

It's definitely possible to upgrade the module. However, as Boris said it's suggested to actually exclude the module from your deployment and include both log4j-api and log4j-core in your deployment https://docs.wildfly.org/25/Admin_Guide.html#how-do-i-log4j2.

[Jens Pelzetter]

Thanks for the hint. I removed log4j-core from my deployment and set the scope for log4j-api to provided. So far everything works as expected.

[Brian Stansberry]

Thank you all for the discussion here!

I've written a more in-depth article on this subject -- please see https://www.wildfly.org/news/2021/12/13/Log4j-CVEs.

Apparently the 280 char tweet limit is inadequate for some topics. ;)

Please do continue to post back if you have more questions or have further information to report.

Best regards,

Brian Stansberry

Project Lead, WildFly

[emran sayed]

Hi All

We are using presently log4j-1.2.17 Version its affected vulnerability or not please suggest what I can do

Regards

Emran Sayed

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/f10186d2-5eb3-438a-b048-2a3f9f539bc7n%40googlegroups.com.

[James Perkins]

Hi Emran Sayed,

There are some notes in the blog post about it https://www.wildfly.org/news/2021/12/13/Log4j-CVEs/#cve-2021-4104. In short though an attacker would be required to have write access to your logging configuration to exploit the CVE for log4j 1.x. It looks like you include log4j in your deployment. As long as you're not using a JMSAppender you should be safe. Even if you are you're still likely safe, but just make sure you do not expose any write access to your log4j configuration or any write access via the log4j LogManager. Both of these would write options would be highly unlikely.

[emran sayed]

Dear James Perkins,

Thank you such your valuable information

Regards

Emran Sayed

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/d69d8fa2-68e5-444f-9751-23f3050003c3n%40googlegroups.com.

[Karl Krasnowsky]

Hi Jens,

I'm running into the exact same problem. Have you found a solution?

thanks,

Karl

On Monday, December 13, 2021 at 8:25:19 AM UTC-8 jens.pe...@googlemail.com wrote:

[James Perkins]

Hi Karl,

If you want to use log4j-core you need to exclude the org.apache.logging.log4j.api module from your deployment. Then include both the log4j-api and log4j-core libraries https://docs.wildfly.org/25/Admin_Guide.html#how-do-i-log4j2.