Regarding WildFly and Log4j 1.x

[KGA Official]

Hi Folks,

Coming from https://www.wildfly.org/news/2021/12/13/Log4j-CVEs/

I understand WildFly has a "shaded" copy of Log4J 1.x in the form of: org.jboss.logmanager:log4j-jboss-logmanager

I know we aren't vulnerable technically. , but our requirement/directive is to "no longer ship" Log4J 1.x.

Is it possible to simply remove the log4j-jboss-logmanager module from WildFly?

Is that used by WildFly internally or was it provided to benefit applications who might need it?

Any plans for WildFly to stop shipping this in the future?

Thanks,

Regards,

Akshay

[philippe....@gmail.com]

Hello

"log4j-jboss-logmanager" is not a "shaded copy", it "shades" the log4j1 classes meaning it offers classes with the same name and methods as log4j1 classes but with a vastly different implementation that uses jboss-logmanager. See for yourself [1]. I assume it's intended for applications that are programmed against log4j but want to make use of the unified logging in WildFly. I think you should be able to just delete the module.

 [1] https://github.com/jboss-logging/log4j-jboss-logmanager

Cheers

Philippe

[James Perkins]

To answer the "Is it possible to simply remove the log4j-jboss-logmanager module from WildFly?", no. There are modules that require log4j 1.x still and it cannot be removed.

[KGA Official]

Interesting view.

So, from a technical standpoint I should treat "log4j-jboss-logmanager" as an actively maintained component of WildFly and doesn't fall into the "obsolete" category of Log4J 1.x.

Thus, in theory applications that are using Log4J1.x _via_ log4j-jboss-manager and running on WildFly can continue to remain there and not be worried.

Is that a fair enough statement?

Because a counter point:

"Despite a vastly different implementation", I do see that all "vulnerabilities" that applied to Log4J 1.x were also present in the code here, but might not be executable due to other defaults.

Thanks,

Regards,

Akshay

[KGA Official]

Thanks.

Are there plans to remove this in upcoming WildFly releases?

Thx,

regards,

Akshay

[James Perkins]

It is maintained, but it does shade in most of log4j. Mostly it just replaces the log manager parts to delegate to the jboss-logmanager.

As much as I'd love to see it removed, I don't see that being possible anytime soon.

[Usman Ashraf]

Hey,

Just to confirm again,  log4j-jboss-logmanage is not open to vulnerabilities just like Log4j 1.X and safe to use in our projects? Right?

[James Perkins]

Hello,

The log4j-jboss-logmanager does bring in log4j types. However, the only way you'd be vulnerable is if an attacker could change your log4j.properties or log4j.xml file in your deployment. If you don't have either of those you are not vulnerable at all.