A flaw was found in the Java logging library Apache Log4j in version 1.x . This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender. In 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input This flaw in Log4j 2.x is tracked via CVE-2021-44228
Created log4j tracking bugs for this issue: Affects: fedora-all [bug 2031679]
https://github.com/apache/logging-log4j2/pull/608 Note that log4j 1.x is End of Life and has other security vulnerabilities that will not be fixed https://logging.apache.org/log4j/1.2/ https://www.cvedetails.com/cve/CVE-2019-17571/
Red Hat Satellite bundles log4j-over-slf4j with Candlepin, however, product is not affected as it does not make use of JMSAppender method and use logback framework for logging.
Hi there, I don't understand how this vulnerability can be considered like the original one in 2.x. 1) you need to gain access to the log4j.properties file 2) you can execute a command only by putting it in the properties TopicBindingName or TopicConnectionFactoryBindingName. 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://host:port/a >>>log4j.appender.jms.TopicConnectionFactoryBindingName=ldap://host:port/a So it's not input-driven like the CVE-2021-44228. In a situation like this, I don't understand how an attacker can (as written in the title) do a "Remote code execution". In the worst scenario it can be a "local code execution" after he already gained server access...am I wrong? Thank you!
In reply to comment #14: > Hi there, > > I don't understand how this vulnerability can be considered like the > original one in 2.x. > > 1) you need to gain access to the log4j.properties file > 2) you can execute a command only by putting it in the properties > TopicBindingName or TopicConnectionFactoryBindingName. 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://host:port/a > >>>log4j.appender.jms.TopicConnectionFactoryBindingName=ldap://host:port/a > > So it's not input-driven like the CVE-2021-44228. In a situation like this, > I don't understand how an attacker can (as written in the title) do a > "Remote code execution". In the worst scenario it can be a "local code > execution" after he already gained server access...am I wrong? Thank you! that is correct. I have updated the CVE description just now to include as much details as possible regarding the conditions required to exploit the flaw.
Marking Red Hat EAP-XP 3 as not affected; the product does not directly ship log4j, but consumes artifacts from base EAP.
Marking JDG-8 as not affected as it does not ship log4j version 1 anywhere with its distribution.
(In reply to Paramvir jindal from comment #23) > In reply to comment #14: > > Hi there, > > > > I don't understand how this vulnerability can be considered like the > > original one in 2.x. > > > > 1) you need to gain access to the log4j.properties file > > 2) you can execute a command only by putting it in the properties > > TopicBindingName or TopicConnectionFactoryBindingName. 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://host:port/a > > >>>log4j.appender.jms.TopicConnectionFactoryBindingName=ldap://host:port/a > > > > So it's not input-driven like the CVE-2021-44228. In a situation like this, > > I don't understand how an attacker can (as written in the title) do a > > "Remote code execution". In the worst scenario it can be a "local code > > execution" after he already gained server access...am I wrong? Thank you! > > that is correct. I have updated the CVE description just now to include as > much details as possible regarding the conditions required to exploit the > flaw. Thank you Paramvir! In this case, the only real solution would be to give proper read/write permission to our application files, right? If I simply update my log4j to the latest fixed version (2.15), I would still be vulnerable, since an attacker that has gained access to my server can also replace my log4j jar with a previous version. what do you think? Thanks again!
Please add status for Red Hat Enterprise Linux 6, which is still covered by ELS. Thanks,
I agree with Carlo de Wolf and others: there is no log4j v2 exploit here. Other vendors, such as Apache, Snyk, Microsoft, Atlassian etc. have reviewed log4j v1 too, specifically with the JMSAppender concern. Including a couple of references: https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html "We have done additional analysis on this fork and confirmed a new but similar vulnerability that can only be exploited by a trusted party. For that reason, Atlassian rates the severity level for on-premises products as low. Specifically, Atlassian products that use Log4j 1.x are only affected if all of the following non-default configurations are in place: The JMS Appender is configured in the application's Log4j configuration The javax.jms API is included in the application's CLASSPATH The JMS Appender has been configured with a JNDI lookup to a third party. Note: this can only be done by a trusted user modifying the application's configuration, or by trusted code setting a property at runtime " And https://lists.apache.org/thread/lgbtvvmy68p0059yoyn9qxzosdmx4jdv "1. As *log4j 1.x* does NOT offer a JNDI look up mechanism at the message level,* it does NOT suffer from CVE-2021-44228.* 2. However, log4j 1.x comes with JMSAppender which will perform JNDI lookup if enabled in log4j's configuration file, i.e. *log4j.properties* or *log4j.xml*. 3. In the absense of a new log4j 1.x release, you can remove JMSAppender from *log4j-1.2.17.jar* artifact yourself. (commands are listed in the page <http://slf4j.org/log4shell.html>) 4. Therefore, in addition to hardening KNOWN vulnerable components in aforementioned frameworks, we also recommend that *configuration files be protected against write access*. In Unix-speak they should be *read-only for all users, including the owner*. If possible, they should also be monitored against changes and unauthorized manipulation."
Can we confirm whether or not we'll provide an update for verion 1.x ? Specifically 1.2.17? Or will this be considered not affected?
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.8 Via RHSA-2021:5148 https://access.redhat.com/errata/RHSA-2021:5148
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.6 Via RHSA-2021:5141 https://access.redhat.com/errata/RHSA-2021:5141
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.7 Via RHSA-2021:5107 https://access.redhat.com/errata/RHSA-2021:5107
In reply to comment #50: > Can we confirm whether or not we'll provide an update for verion 1.x ? > Specifically 1.2.17? Or will this be considered not affected? Providing or using a patched log4j 1.x version is at the discretion of the particular affected product's team. Note: This is a moderate impact CVE and may be out of support scope for some products listed, these are detailed on our life-cycle pages - https://access.redhat.com/support/policy/updates/jboss_notes/
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.8 Via RHSA-2021:5183 https://access.redhat.com/errata/RHSA-2021:5183
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.7 Via RHSA-2021:5184 https://access.redhat.com/errata/RHSA-2021:5184
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.6 Via RHSA-2021:5186 https://access.redhat.com/errata/RHSA-2021:5186
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Extended Lifecycle Support Red Hat Enterprise Linux 7.3 Advanced Update Support Red Hat Enterprise Linux 7.4 Advanced Update Support Red Hat Enterprise Linux 7.6 Advanced Update Support Red Hat Enterprise Linux 7.6 Update Services for SAP Solutions Red Hat Enterprise Linux 7.6 Telco Extended Update Support Red Hat Enterprise Linux 7.7 Advanced Update Support Red Hat Enterprise Linux 7.7 Update Services for SAP Solutions Red Hat Enterprise Linux 7.7 Telco Extended Update Support Red Hat Enterprise Linux 7 Via RHSA-2021:5206 https://access.redhat.com/errata/RHSA-2021:5206
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Via RHSA-2021:5269 https://access.redhat.com/errata/RHSA-2021:5269
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-4104
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions Via RHSA-2022:0294 https://access.redhat.com/errata/RHSA-2022:0294
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:0290 https://access.redhat.com/errata/RHSA-2022:0290
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Extended Update Support Via RHSA-2022:0291 https://access.redhat.com/errata/RHSA-2022:0291
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Extended Update Support Via RHSA-2022:0289 https://access.redhat.com/errata/RHSA-2022:0289
This issue has been addressed in the following products: Red Hat Data Grid 7.3.9 Via RHSA-2022:0430 https://access.redhat.com/errata/RHSA-2022:0430
This issue has been addressed in the following products: EAP 7.4 log4j async Via RHSA-2022:0435 https://access.redhat.com/errata/RHSA-2022:0435
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 7.4 on RHEL 7 Red Hat JBoss Enterprise Application Platform 7.4 for RHEL 8 Via RHSA-2022:0436 https://access.redhat.com/errata/RHSA-2022:0436
This issue has been addressed in the following products: EAP 6.4 log4j async Via RHSA-2022:0437 https://access.redhat.com/errata/RHSA-2022:0437
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6 Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 7 Via RHSA-2022:0438 https://access.redhat.com/errata/RHSA-2022:0438
This issue has been addressed in the following products: RHEL-8 based Middleware Containers Via RHSA-2022:0444 https://access.redhat.com/errata/RHSA-2022:0444
This issue has been addressed in the following products: Red Hat Single Sign-On 7.4.10 Via RHSA-2022:0446 https://access.redhat.com/errata/RHSA-2022:0446
This issue has been addressed in the following products: RHSSO 7.5.1 Via RHSA-2022:0449 https://access.redhat.com/errata/RHSA-2022:0449
This issue has been addressed in the following products: Red Hat Single Sign-On 7.5 for RHEL 8 Via RHSA-2022:0448 https://access.redhat.com/errata/RHSA-2022:0448
This issue has been addressed in the following products: Red Hat Single Sign-On 7.5 for RHEL 7 Via RHSA-2022:0447 https://access.redhat.com/errata/RHSA-2022:0447
This issue has been addressed in the following products: RHEL-8 based Middleware Containers Via RHSA-2022:0445 https://access.redhat.com/errata/RHSA-2022:0445
This issue has been addressed in the following products: RHEL-8 based Middleware Containers Via RHSA-2022:0450 https://access.redhat.com/errata/RHSA-2022:0450
This issue has been addressed in the following products: Red Hat Virtualization Engine 4.4 Via RHSA-2022:0475 https://access.redhat.com/errata/RHSA-2022:0475
This issue has been addressed in the following products: Red Hat JBoss Data Virtualization 6.4.8.SP1 Via RHSA-2022:0497 https://access.redhat.com/errata/RHSA-2022:0497
This issue has been addressed in the following products: Red Hat JBoss Data Virtualization 6.4.8.SP2 Via RHSA-2022:0507 https://access.redhat.com/errata/RHSA-2022:0507
This issue has been addressed in the following products: Red Hat JBoss Web Server 3 for RHEL 7 Via RHSA-2022:0524 https://access.redhat.com/errata/RHSA-2022:0524
This issue has been addressed in the following products: Red Hat JBoss Web Server Via RHSA-2022:0527 https://access.redhat.com/errata/RHSA-2022:0527
This issue has been addressed in the following products: Red Hat Fuse/AMQ 6.3.20 Via RHSA-2022:0553 https://access.redhat.com/errata/RHSA-2022:0553
This issue has been addressed in the following products: Red Hat Fuse 7.10.1 Via RHSA-2022:0661 https://access.redhat.com/errata/RHSA-2022:0661
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 7.4 on RHEL 7 Via RHSA-2022:1296 https://access.redhat.com/errata/RHSA-2022:1296
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 7.4 for RHEL 8 Via RHSA-2022:1297 https://access.redhat.com/errata/RHSA-2022:1297
This issue has been addressed in the following products: EAP 7.4.4 release Via RHSA-2022:1299 https://access.redhat.com/errata/RHSA-2022:1299
This issue has been addressed in the following products: EAP 6.4.24 release Via RHSA-2022:5458 https://access.redhat.com/errata/RHSA-2022:5458
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 6 Via RHSA-2022:5459 https://access.redhat.com/errata/RHSA-2022:5459
This issue has been addressed in the following products: Red Hat JBoss Enterprise Application Platform 6.4 for RHEL 7 Via RHSA-2022:5460 https://access.redhat.com/errata/RHSA-2022:5460
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days