wildfly 9.0.2 and log4j v1

[Siddhartha Sharma]

Hello,

Do the following log4j v1 vulnerabilities affect WILDFLY 9.0.2 ? 

We do not have a log4j property / xml file.

CVE-2019-17571 is a high severity issue targeting the SocketServer. Log4j includes a SocketServer that accepts serialized log events and deserializes them without verifying whether the objects are allowed or not. This can provide an attack vector that can be expoited.

CVE-2020-9488 is a moderate severity issue with the SMTPAppender. Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender.

CVE-2021-4104 is a high severity deserialization vulnerability in JMSAppender. JMSAppender uses JNDI in an unprotected manner allowing any application using the JMSAppender to be vulnerable if it is configured to reference an untrusted site or if the site referenced can be accesseed by the attacker. For example, the attacker can cause remote code execution by manipulating the data in the LDAP store.

CVE-2022-23302 is a high severity deserialization vulnerability in JMSSink. JMSSink uses JNDI in an unprotected manner allowing any application using the JMSSink to be vulnerable if it is configured to reference an untrusted site or if the site referenced can be accesseed by the attacker. For example, the attacker can cause remote code execution by manipulating the data in the LDAP store.

CVE-2022-23305 is a high serverity SQL injection flaw in JDBCAppender that allows the data being logged to modify the behavior of the component. By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed.

CVE-2022-23307 is a critical severity against the chainsaw component in Log4j 1.x. This is the same issue corrected in CVE-2020-9493 fixed in Chainsaw 2.1.0 but Chainsaw was included as part of Log4j 1.2.x.

[Brian Stansberry]

Hi,

WildFly 9.0.2 is quite old so I'm not going to comment on specifics about that release. I do recommend that you move to WildFly 26.1.2 or 27, as the way we resolve CVEs is by fixing them in the current release. 

However, please have a look at the following items, which discuss the impact of the various log4j CVEs on WildFly:

1) https://www.wildfly.org/news/2021/12/13/Log4j-CVEs/

2) https://groups.google.com/g/wildfly/c/DlmSXVXKU7Y/m/H5DJqlTeCQAJ

3) https://groups.google.com/g/wildfly/c/f3Wt3kkFJ6M/m/IVSSP9wkBQAJ

Best regards,

Brian Stansberry

WildFly Project Lead

[Siddhartha Sharma]

updating wildfly is not an option for us at this current time  because of timelines and resourcing hence the question.

as per : https://groups.google.com/g/wildfly/c/EejAQ-LKWRA/m/ouWrKcjeCAAJ. This talks about how its not exploitable if there is not log4j.property/xml etc .

However,  this does not talk about what wildfly versions but just a blanket statement

Can we please get some guidance on wildfly 9.0.2 ? 

Will be hugely appreciative of that. 

Longterm option will be probably upgrade wildfly or eap.

[James Perkins]

It would be the same for all versions of WildFly. The log4j-jboss-logmanager library is only used if you use log4j in your deployment and only configured if you have a log4j.properties/xml file.

[Siddhartha Sharma]

Is it possible to get some support for wildfly 9.0.2 to get an updated version of “Log4j-jboss-logmanager” into WildFly 9.0.2  with say log4j2 or something else that does not have the log4j v1 vulnerabilities listed below 
as well as other log4jv2 vulnerabilities ?