Regarding WildFly and Log4j 1.x

128 views
Skip to first unread message

KGA Official

unread,
Jan 6, 2022, 12:56:23 AMJan 6
to WildFly
Hi Folks,


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

unread,
Jan 6, 2022, 7:40:54 AMJan 6
to WildFly
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.

James Perkins

unread,
Jan 6, 2022, 11:44:39 AMJan 6
to WildFly
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

unread,
Jan 7, 2022, 3:54:56 AMJan 7
to WildFly
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

unread,
Jan 7, 2022, 3:56:00 AMJan 7
to WildFly
Thanks.
Are there plans to remove this in upcoming WildFly releases?

Thx,
regards,
Akshay

James Perkins

unread,
Jan 7, 2022, 11:40:30 AMJan 7
to WildFly
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

unread,
Jan 17, 2022, 10:40:34 AMJan 17
to WildFly
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

unread,
Jan 17, 2022, 10:51:11 AMJan 17
to WildFly
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.

Reply all
Reply to author
Forward
0 new messages