Is sqlg affected by log4j 1.x security vulnerabilities?

[antheil]

Sqlg depends on log4j 1.2.17. We were recentily informed that three vulnerabilities were found in Apache Log4j 1.x in January 2022. They were classified as critical. Is sqlg affected by these vulnerabilities?

https://logging.apache.org/log4j/1.2/

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.

[pietermartin]

Sqlg does not internally use JMSSink, JDBCAppender or Chainsaw. So no these vulnerabilities do not affect sqlg.

[pietermartin]

Also Sqlg does not have an internal log4j.properties file, it uses the one supplied by the user.

[antheil]

Ok, thanks.