Описание
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. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. 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.
A flaw was found in the Java logging library Apache Log4j in version 1.x. JDBCAppender in Log4j 1.x is vulnerable to SQL injection in untrusted data. This allows a remote attacker to run SQL statements in the database if the deployed application is configured to use JDBCAppender with certain interpolation tokens.
Отчет
Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Red Hat Satellite bundles log4j-over-slf4j with Candlepin, however, product is not affected as it uses logback framework for logging. Red Hat Virtualization and OpenShift Container Platform in the OCP Metering stack (the Hive/Presto/Hadoop components) ship a vulnerable version of the log4j package, however JDBCAppender is not used. Therefore the impact of this vulnerability for these products is rated Low.
Меры по смягчению последствий
These are the possible mitigations for this flaw for releases version 1.x:
- Comment out or remove JDBCAppender in the Log4j configuration if it is used
- Remove the JDBCAppender class from the server's jar files. For example:
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| A-MQ Clients 2 | log4j | Affected | ||
| Red Hat AMQ Broker 7 | log4j | Affected | ||
| Red Hat build of Quarkus | log4j | Not affected | ||
| Red Hat CodeReady Studio 12 | log4j | Affected | ||
| Red Hat Data Grid 8 | log4j | Not affected | ||
| Red Hat Decision Manager 7 | log4j | Not affected | ||
| Red Hat Enterprise Linux 7 | tomcat | Not affected | ||
| Red Hat Integration Camel K 1 | log4j | Not affected | ||
| Red Hat Integration Camel Quarkus 1 | log4j | Not affected | ||
| Red Hat JBoss Enterprise Application Platform Expansion Pack | log4j | Not affected |
Показывать по
Дополнительная информация
Статус:
EPSS
8.8 High
CVSS3
Связанные уязвимости
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. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. 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.
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. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. 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.
By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as ...
Уязвимость адаптера JDBCAppender программы для журналирования Java-программ Log4j, позволяющая нарушителю выполнять произвольные SQL-запросы к базе данных
EPSS
8.8 High
CVSS3