Summary

Log4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser. As per Apache's Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, 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. From log4j 2.16.0, this behavior has been disabled by default.

Log4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the Updated advice for version 2.16.0 section of this advisory.

Impact

Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input.

Affected versions

Any Log4J version prior to v2.15.0 is affected to this specific issue.

The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible.

Security releases Additional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3

Affected packages Only the org.apache.logging.log4j:log4j-core package is directly affected by this vulnerability. The org.apache.logging.log4j:log4j-api should be kept at the same version as the org.apache.logging.log4j:log4j-core package to ensure compatability if in use.

Remediation Advice

Updated advice for version 2.16.0

The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which disables JNDI by default and completely removes support for message lookups. Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as CVE-2021-45046. More information is available on the GitHub Security Advisory for CVE-2021-45046.

Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded.

Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible.

A flaw was discovered in FasterXML jackson-databind, where it would permit polymorphic deserialization of malicious objects using the ehcache and logback JNDI gadgets when used in conjunction with polymorphic type handling methods such as enableDefaultTyping() or when @JsonTypeInfo is using Id.CLASS or Id.MINIMALCLASS or in any other way which ObjectMapper.readValue might instantiate objects from unsafe sources. An attacker could use this flaw to execute arbitrary code.

A use after free can have a range of potential consequences such as the corruption of valid data, crashes or execution of arbitrary code. However, only applications that directly call the SSLfreebuffers function are affected by this issue. Applications that do not call this function are not vulnerable. Our investigations indicate that this function is rarely used by applications.

The SSLfreebuffers function is used to free the internal OpenSSL buffer used when processing an incoming record from the network. The call is only expected to succeed if the buffer is not currently in use. However, two scenarios have been identified where the buffer is freed even when still in use.

The first scenario occurs where a record header has been received from the network and processed by OpenSSL, but the full record body has not yet arrived. In this case calling SSLfreebuffers will succeed even though a record has only been partially processed and the buffer is still in use.

The second scenario occurs where a full record containing application data has been received and processed by OpenSSL but the application has only read part of this data. Again a call to SSLfreebuffers will succeed even though the buffer is still in use.

While these scenarios could occur accidentally during normal operation a malicious attacker could attempt to engineer a stituation where this occurs. We are not aware of this issue being actively exploited.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

OpenSSL 1.0.2 is also not affected by this issue.

OpenSSL 3.3, 3.2, 3.1, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.1 once it is released.

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.2 once it is released.

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.6 once it is released.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.14 once it is released.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1y once it is released (premium support customers only).

Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit e5093133c3 (for 3.3), commit c88c3de510 (for 3.2), commit 704f725b96 (for 3.1) and commit b3f0eb0a29 (for 3.0) in the OpenSSL git repository. It is available to premium support customers in commit f7a045f314 (for 1.1.1).

This issue was reported on 10th April 2024 by William Ahern (Akamai). The fix was developed by Matt Caswell and Watson Ladd (Akamai).

gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4CONNMSGLEN is not sufficient for a trailing '\0' character.

A flaw was found in jackson-databind 2.x. FasterXML jackson-databind 2.x mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind 2.x. FasterXML jackson-databind 2.x mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind 2.x in versions prior to 2.9.10.4. FasterXML jackson-databind 2.x mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in OpenSSL. The crehash script does not properly sanitize shell meta-characters to prevent command injection. Some operating systems distribute this script in a manner where it is automatically executed. This flaw allows an attacker to execute arbitrary commands with the privileges of the script on these operating systems.

A flaw was found in the Undertow DEBUG log for io.undertow.request.security. If enabled, an attacker could abuse this flaw to obtain the user’s credentials from the log files.

A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 prior to 2.9.10.1, 2.8.11.5, and 2.6.7.3. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the p6spy (3.8.6) jar in the classpath, and an attacker can find an RMI service endpoint to access, it is possible to make the service execute a malicious payload. This issue exists because of com.p6spy.engine.spy.P6DataSource mishandling.

A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 through 2.9.10. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the commons-dbcp (1.4) jar in the classpath, and an attacker can find an RMI service endpoint to access, it is possible to make the service execute a malicious payload. This issue exists because of org.apache.commons.dbcp.datasources.SharedPoolDataSource and org.apache.commons.dbcp.datasources.PerUserPoolDataSource mishandling.

A flaw was found in jackson-databind before 2.9.10. New serialization gadgets were found regarding a class of the ehcache package which may help in exploiting deserialization issues.

Upstream issue:

https://github.com/FasterXML/jackson-databind/issues/2460

Upstream patch:

https://github.com/FasterXML/jackson-databind/commit/191a4cdf87b56d2ddddb77edd895ee756b7f75eb

References:

https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062

An integer wraparound was discovered in glib due to passing a 64 bit sized value to function gmemdup() which accepts a 32 bits number as argument. An attacker may abuse this flaw when an application linked against the glib library uses gbytesnew() function or possibly other functions that use gmemdup() underneath and accept a 64 bits argument as size. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A use-after-free vulnerability was found in systemd. This issue occurs due to the onstreamio() function and dnsstreamcomplete() function in 'resolved-dns-stream.c' not incrementing the reference counting for the DnsStream object. Therefore, other functions and callbacks called can dereference the DNSStream object, causing the use-after-free when the reference is still used later.

A flaw was found in Spring Security. When using RegexRequestMatcher, an easy misconfiguration can bypass some servlet containers. Applications using RegexRequestMatcher with . in the regular expression are possibly vulnerable to an authorization bypass.

A vulnerability was found in Undertow web server before 2.0.21. An information exposure of plain text credentials through log files because Connectors.executeRootHandler:402 logs the HttpServerExchange object at ERROR level using UndertowLogger.REQUESTLOGGER.undertowRequestFailed(t, exchange)

A flaw was found in Node.js. These vulnerabilities include remote code execution, Cross-site scripting (XSS), application crashes due to missing input validation of hostnames returned by Domain Name Servers in the Node.js DNS library, which can lead to the output of wrong hostnames (leading to Domain hijacking) and injection vulnerabilities in applications using the library.

A flaw was found in openssl. A miscalculation of a buffer size was found in openssl's SM2 decryption function, allowing up to 62 arbitrary bytes to be written outside of the buffer. A remote attacker could use this flaw to crash an application supporting SM2 signature or encryption algorithm, or, possibly, execute arbitrary code with the permissions of the user running that application. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in the Linux kernel. A heap based buffer overflow in mwifiexuapparsetailies function in drivers/net/wireless/marvell/mwifiex/ie.c might lead to memory corruption and possibly other consequences.

A flaw was found in python. A stack-based buffer overflow was discovered in the ctypes module provided within Python. Applications that use ctypes without carefully validating the input passed to it may be vulnerable to this flaw, which would allow an attacker to overflow a buffer on the stack and crash the application. The highest threat from this vulnerability is to system availability.

FasterXML jackson-databind 2.x before 2.6.7.4, 2.7.x before 2.7.9.7, 2.8.x before 2.8.11.5, and 2.9.x before 2.9.10.2 lacks certain net.sf.ehcache blocking.

A flaw was found in quartz through version 2.3.0. A XXE attack is possible in the Terracotta Quartz Scheduler using a job description. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in the spring-security framework. Spring Security could allow a remote attacker to bypass security restrictions caused by an issue when using forward or include dispatcher types. By sending a specially-crafted request, an attacker can bypass authorization rules.

A vulnerability was found in lz4, where a potential memory corruption due to an integer overflow bug which caused one of the memmove arguments to become negative. Depending on how the library was compiled this will hit an assert() inside the library and dump core, leaving a 4GB core file, or it wil go into libc and crash inside the memmove() function.

Reference: https://github.com/lz4/lz4/pull/972

A flaw was found in grub2 when handling split HTTP headers. While processing a split HTTP header, grub2 wrongly advances its control pointer to the internal buffer by one position, which can lead to an out-of-bounds write. This flaw allows an attacker to leverage this issue by crafting a malicious set of HTTP packages making grub2 corrupt its internal memory metadata structure. This leads to data integrity and confidentiality issues or forces grub to crash, resulting in a denial of service attack.

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

An old inffast.c optimization turns out to not be optimal anymore with modern compilers, and furthermore was not compliant with the C standard, for which decrementing a pointer before its allocated memory is undefined.

External References:

https://wiki.mozilla.org/images/0/09/Zlib-report.pdf https://docs.google.com/document/d/10i1KZS5so8xDqH2rplRa2xet0tyTvvJlLbQQmZIUIKE/edit#heading=h.t13tvnx4loq7

Upstream patch:

https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb

CVE assignment:

http://seclists.org/oss-sec/2016/q4/602

An upgrade to zlib 1.2.11 to fix a number of low severity CVEs that were present in zlib 1.2.8.

A security vulnerability was found in zlib. The flaw triggered a heap-based buffer in inflate in the inflate.c function via a large gzip header extra field. This flaw is only applicable in the call inflateGetHeader.

libxslt through 1.1.33 allows bypass of a protection mechanism because callers of xsltCheckRead and xsltCheckWrite permit access even upon receiving a -1 error code. xsltCheckRead can return -1 for a crafted URL that is not actually invalid and is subsequently loaded.