Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2021.4186.4
Apache Log4j2 Security Update
5 January 2022
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: log4j2
Publisher: The Apache Foundation
Operating System: Windows
UNIX variants (UNIX, Linux, OSX)
Impact/Access: Execute Arbitrary Code/Commands -- Remote/Unauthenticated
Denial of Service -- Remote/Unauthenticated
Resolution: Patch/Upgrade
CVE Names: CVE-2021-45105 CVE-2021-45046 CVE-2021-44832
CVE-2021-44228 CVE-2021-4104
Reference: ASB-2021.0244
Original Bulletin:
https://logging.apache.org/log4j/2.x/security.html
Comment: UPDATE: Apache have released version 2.16.0 for log4j2.
Revision History: January 5 2022: Updated versions for log4j2 released to address new CVEs
December 15 2021: log4j2 2.16.0 patch notes released and additional CVE added
December 14 2021: Added comment advising of new version of log4j2
December 13 2021: Initial Release
- --------------------------BEGIN INCLUDED TEXT--------------------
Fixed in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6)
CVE-2021-44832: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker
controls configuration.
CVE-2021-44832 Remote Code Execution
Severity Moderate
Base CVSS Score 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Versions All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and
Affected 2.12.4
Description
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix
releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE)
attack where an attacker with permission to modify the logging configuration
file can construct a malicious configuration using a JDBC Appender with a data
source referencing a JNDI URI which can execute remote code. This issue is
fixed by limiting JNDI data source names to the java protocol in Log4j2
versions 2.17.1, 2.12.4, and 2.3.2.
Mitigation
Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation
Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8
and later).
In prior releases confirm that if the JDBC Appender is being used it is not
configured to use any protocol other than Java.
Note that only the log4j-core JAR file is impacted by this vulnerability.
Applications using only the log4j-api JAR file without the log4j-core JAR file
are not impacted by this vulnerability.
Also note that Apache Log4j is the only Logging Services subproject affected by
this vulnerability. Other projects like Log4net and Log4cxx are not impacted by
this.
Release Details
- From version 2.17.1, (and 2.12.4 and 2.3.2 for Java 7 and Java 6), the JDBC
Appender will use JndiManager and will require the log4j2.enableJndiJdbc system
property to contain a value of true for JNDI to be enabled.
The property to enable JNDI has been renamed from 'log4j2.enableJndi' to three
separate properties: log4j2.enableJndiLookup, log4j2.enableJndiJms, and
log4j2.enableJndiContextSelector.
JNDI functionality has been hardened in these versions: 2.3.1, 2.12.2, 2.12.3
or 2.17.0: from these versions onwards, support for the LDAP protocol has been
removed and only the JAVA protocol is supported in JNDI connections.
Work in progress
The Log4j team will continue to actively update this page as more information
becomes known.
Credit
No credit is being awarded for this issue.
References
o CVE-2021-44832
Fixed in Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) and 2.3.1 (Java 6)
CVE-2021-45105: Apache Log4j2 does not always protect from infinite recursion
in lookup evaluation
CVE-2021-45105 Denial of Service
Severity Moderate
Base CVSS Score 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Versions Affected All versions from 2.0-beta9 to 2.16.0, excluding 2.12.3
Description
Apache Log4j2 versions 2.0-alpha1 through 2.16.0, excluding 2.12.3, did not
protect from uncontrolled recursion from self-referential lookups. When the
logging configuration uses a non-default Pattern Layout with a Context Lookup
(for example, $${ctx:loginId}), attackers with control over Thread Context Map
(MDC) input data can craft malicious input data that contains a recursive
lookup, resulting in a StackOverflowError that will terminate the process. This
is also known as a DOS (Denial of Service) attack.
Mitigation
Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation
Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8
and later).
Alternatively, this infinite recursion issue can be mitigated in configuration:
o In PatternLayout in the logging configuration, replace Context Lookups like
${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X,
%mdc, or %MDC).
o Otherwise, in the configuration, remove references to Context Lookups like
${ctx:loginId} or $${ctx:loginId} where they originate from sources
external to the application such as HTTP headers or user input.
Note that only the log4j-core JAR file is impacted by this vulnerability.
Applications using only the log4j-api JAR file without the log4j-core JAR file
are not impacted by this vulnerability.
Also note that Apache Log4j is the only Logging Services subproject affected by
this vulnerability. Other projects like Log4net and Log4cxx are not impacted by
this.
Release Details
- From version 2.17.0, (and 2.12.3 and 2.3.1 for Java 7 and Java 6), only lookup
strings in configuration are expanded recursively; in any other usage, only the
top-level lookup is resolved, and any nested lookups are not resolved.
The property to enable JNDI has been renamed from 'log4j2.enableJndi' to three
separate properties: 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and
'log4j2.enableJndiContextSelector'.
JNDI functionality has been hardened in these versions: 2.3.1, 2.12.2, 2.12.3
or 2.17.0: from these versions onwards, support for the LDAP protocol has been
removed and only the JAVA protocol is supported in JNDI connections.
Work in progress
The Log4j team will continue to actively update this page as more information
becomes known.
Credit
Independently discovered by Hideki Okamoto of Akamai Technologies, Guy
Lederfein of Trend Micro Research working with Trend Micro's Zero Day
Initiative, and another anonymous vulnerability researcher.
References
o CVE-2021-45105
o LOG4J2-3230
Fixed in Log4j 2.16.0 (Java 8) and Log4j 2.12.2 (Java 7)
CVE-2021-45046: Apache Log4j2 Thread Context Lookup Pattern vulnerable to
remote code execution in certain non-default configurations
CVE-2021-45046 Remote Code Execution
Severity Critical
Base CVSS Score 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
Versions Affected All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2
Description
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was
incomplete in certain non-default configurations. When the logging
configuration uses a non-default Pattern Layout with a Context Lookup (for
example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC)
input data can craft malicious input data using a JNDI Lookup pattern,
resulting in an information leak and remote code execution in some environments
and local code execution in all environments; remote code execution has been
demonstrated on MacOS, Fedora, Arch Linux, and Alpine Linux.
Mitigation
Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation
Implement one of the following mitigation techniques:
o Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for
Java 8 and later).
o Otherwise, in any release other than 2.16.0, you may remove the JndiLookup
class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/
log4j/core/lookup/JndiLookup.class
Users are advised not to enable JNDI in Log4j 2.16.0, since it still allows
LDAP connections. If the JMS Appender is required, use one of these versions:
2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, only the JAVA
protocol is supported in JNDI connections.
Note that only the log4j-core JAR file is impacted by this vulnerability.
Applications using only the log4j-api JAR file without the log4j-core JAR file
are not impacted by this vulnerability.
Also note that Apache Log4j is the only Logging Services subproject affected by
this vulnerability. Other projects like Log4net and Log4cxx are not impacted by
this.
History
Severity is now Critical
The original severity of this CVE was rated as Moderate; since this CVE was
published security experts found additional exploits against the Log4j 2.15.0
release, that could lead to information leaks, RCE (remote code execution) and
LCE (local code execution) attacks.
Base CVSS Score changed from 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) to 9.0
(AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).
The title of this CVE was changed from mentioning Denial of Service attacks to
mentioning Remote Code Execution attacks.
Only Pattern Layouts with a Context Lookup (for example, $${ctx:loginId}) are
vulnerable to this. This page previously incorrectly mentioned that Thread
Context Map pattern (%X, %mdc, or %MDC) in the layout would also allow this
vulnerability.
While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to
localhost by default, there are ways to bypass this and users should not rely
on this.
Older (discredited) mitigation measures
This page previously mentioned other mitigation measures, but we discovered
that these measures only limit exposure while leaving some attack vectors open.
Other insufficient mitigation measures are: setting system property
log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS
to true for releases >= 2.10, or modifying the logging configuration to disable
message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for
releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread
Context attack vector mentioned above, there are still code paths in Log4j
where message lookups could occur: known examples are applications that use
Logger.printf("%s", userInput), or applications that use a custom message
factory, where the resulting messages do not implement
StringBuilderFormattable. There may be other attack vectors.
The safest thing to do is to upgrade Log4j to a safe version, or remove the
JndiLookup class from the log4j-core jar.
Release Details
- From version 2.16.0 (for Java 8), the message lookups feature has been
completely removed. Lookups in configuration still work. Furthermore, Log4j now
disables access to JNDI by default. JNDI lookups in configuration now need to
be enabled explicitly. Users are advised not to enable JNDI in Log4j 2.16.0,
since it still allows LDAP connections. If the JMS Appender is required, use
one of these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions
onwards, only the JAVA protocol is supported in JNDI connections.
- From version 2.12.2 (for Java 7) and 2.3.1 (for Java 6), the message lookups
feature has been completely removed. Lookups in configuration still work.
Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in
configuration now need to be enabled explicitly. When enabled, JNDI will only
support the JAVA protocol, support for the LDAP protocol has been removed.
- From version 2.17.0 (for Java 8), support for the LDAP protocol has been
removed and only the JAVA protocol is supported in JNDI connections.
- From version 2.17.0 (for Java 8), 2.12.3 (for Java 7) and 2.3.1 (for Java 6),
the property to enable JNDI has been renamed from 'log4j2.enableJndi' to three
separate properties: 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and
'log4j2.enableJndiContextSelector'.
Work in progress
The Log4j team will continue to actively update this page as more information
becomes known.
Credit
This issue was discovered by Kai Mindermann of iC Consult and separately by
4ra1n.
Additional vulnerability details discovered independently by Ash Fox of Google,
Alvaro Munoz and Tony Torralba from GitHub, Anthony Weems of Praetorian, and
RyotaK (@ryotkak).
References
o CVE-2021-45046
o LOG4J2-3221
Fixed in Log4j 2.15.0 (Java 8)
CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker
controlled LDAP and other JNDI related endpoints.
CVE-2021-44228 Remote Code Execution
Severity Critical
Base CVSS Score 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Versions Affected All versions from 2.0-beta9 to 2.14.1
Description
In Apache Log4j2 versions up to and including 2.14.1 (excluding security
releases 2.3.1, 2.12.2 and 2.12.3), the JNDI features used in configurations,
log messages, and parameters do not protect against attacker-controlled LDAP
and other JNDI related endpoints. An attacker who can control log messages or
log message parameters can execute arbitrary code loaded from LDAP servers when
message lookup substitution is enabled.
Mitigation
Log4j 1.x mitigation
Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j
1.x are only vulnerable to this attack when they use JNDI in their
configuration. A separate CVE (CVE-2021-4104) has been filed for this
vulnerability. To mitigate: Audit your logging configuration to ensure it has
no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not
impacted by this vulnerability.
Log4j 2.x mitigation
Implement one of the following mitigation techniques:
o Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for
Java 8 and later).
o Otherwise, in any release other than 2.16.0, you may remove the JndiLookup
class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/
log4j/core/lookup/JndiLookup.class
Note that only the log4j-core JAR file is impacted by this vulnerability.
Applications using only the log4j-api JAR file without the log4j-core JAR file
are not impacted by this vulnerability.
Also note that Apache Log4j is the only Logging Services subproject affected by
this vulnerability. Other projects like Log4net and Log4cxx are not impacted by
this.
History
Older (discredited) mitigation measures
This page previously mentioned other mitigation measures, but we discovered
that these measures only limit exposure while leaving some attack vectors open.
The 2.15.0 release was found to still be vulnerable when the configuration has
a Pattern Layout containing a Context Lookup (for example, $${ctx:loginId}).
When an attacker can control Thread Context values, they may inject a JNDI
Lookup pattern, which will be evaluated and result in a JNDI connection. While
Log4j 2.15.0 makes a best-effort attempt to restrict JNDI connections to
localhost by default, there are ways to bypass this and users should not rely
on this.
A new CVE (CVE-2021-45046, see above) was raised for this.
Other insufficient mitigation measures are: setting system property
log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS
to true for releases >= 2.10, or modifying the logging configuration to disable
message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for
releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread
Context attack vector mentioned above, there are still code paths in Log4j
where message lookups could occur: known examples are applications that use
Logger.printf("%s", userInput), or applications that use a custom message
factory, where the resulting messages do not implement
StringBuilderFormattable. There may be other attack vectors.
The safest thing to do is to upgrade Log4j to a safe version, or remove the
JndiLookup class from the log4j-core jar.
Release Details
As of Log4j 2.15.0 the message lookups feature was disabled by default. Lookups
in configuration still work. While Log4j 2.15.0 has an option to enable Lookups
in this fashion, users are strongly discouraged from enabling it. A
whitelisting mechanism was introduced for JNDI connections, allowing only
localhost by default. The 2.15.0 release was found to have additional
vulnerabilities and is not recommended.
- From version 2.16.0 (for Java 8), the message lookups feature has been
completely removed. Lookups in configuration still work. Furthermore, Log4j now
disables access to JNDI by default. JNDI lookups in configuration now need to
be enabled explicitly. Users are advised not to enable JNDI in Log4j 2.16.0,
since it still allows LDAP connections. If the JMS Appender is required, use
one of these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions
onwards, only the JAVA protocol is supported in JNDI connections.
- From version 2.12.2 (for Java 7) and 2.3.1 (for Java 6), the message lookups
feature has been completely removed. Lookups in configuration still work.
Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in
configuration now need to be enabled explicitly. When enabled, JNDI will only
support the JAVA protocol, support for the LDAP protocol has been removed.
- From version 2.17.0 (for Java 8), support for the LDAP protocol has been
removed and only the JAVA protocol is supported in JNDI connections.
- From version 2.17.0 (for Java 8), 2.12.3 (for Java 7) and 2.3.1 (for Java 6),
the property to enable JNDI has been renamed from 'log4j2.enableJndi' to three
separate properties: 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and
'log4j2.enableJndiContextSelector'.
Work in progress
The Log4j team will continue to actively update this page as more information
becomes known.
Credit
This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
References
o https://issues.apache.org/jira/browse/LOG4J2-3201
o https://issues.apache.org/jira/browse/LOG4J2-3198.
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
https://www.auscert.org.au/bulletins/
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQIVAwUBYdUQb+NLKJtyKPYoAQizCw//aegVVeni2mzt/FtYm7vUBFhxA8lg5KmX
gzlZaHBqAQ/KtfNwVPznsR/dZWfydpIGdLiM7hn8zEYE7itHMcCa++wmcUQS6CZF
l+RwJ6PBKG+ba9y7vXIt8YIp2onQ1M4DY0UG3VPimtnoE8bDAn3ERO35OCqMew4q
UR9pRDQzICJQp4QKlO3+oU0lKhZp2UvAulRfL65kRimL2oodc0F/wEdZ1XayhE2R
fHYKeTQ/jKMpyLaWrxdvoN5nJmkqBiJUpGCcrcvs9G3PW3DntbB9faFTnsDxvKja
YnhjBnYVgRzD9p8CVPIk3QFhfOZQ35YdW5DFtcuJjPhPWYL7bz6lxHKIYNFXPuLB
BbyI06uFSTSp3IEQrdrrv3pec8gZ/jnyySMa/uBrgXoyn1htfCs+2y2yMs0+/Cn4
/qXwJ+D+SsPR6aOSiYY5DFF4PIkl4EIisP+QAF6hoQeeq9fqLfuLpJw2TeUb5/zB
TvDuuDWayVkdMH6Ki3MPlQPUks/fHv1sxfzzineah1TyVLUXefqXZz6ykVd1EmJd
93Lnc26jbU/CgrhgsfDXKRn6M1qElJzkIiHDf9xRUDFQMcCmvQ16HkN7/EJA4kgI
zLurAZCaJWE5h1SIsrssIarZzhKEOcPpaPZnVz55EYXUv9MMSe35Sj2Uv0yWG872
jAahm8H8egQ=
=hPR3
-----END PGP SIGNATURE-----