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).
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 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
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)
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.
ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library. Prior to version 2.3.0.0, the default implementation of Validator.getValidDirectoryPath(String, String, File, boolean) may incorrectly treat the tested input string as a child of the specified parent directory. This potentially could allow control-flow bypass checks to be defeated if an attack can specify the entire string representing the 'input' path. This vulnerability is patched in release 2.3.0.0 of ESAPI. As a workaround, it is possible to write one's own implementation of the Validator interface. However, maintainers do not recommend this.
A vulnerability was found in Apache Avro. The project would be affected if it accepts an Avro schema for parsing provided by the end-user. By using the special "java-class" attribute an attacker can trigger remote code execution. The issue is fixed in Avro 1.11.4 and 1.12.0.
Issue summary: Calling the OpenSSL API function SSLselectnextproto with an empty supported client protocols buffer may cause a crash or memory contents to be sent to the peer.
A Prototype Pollution vulnerability was found in lodash. Calling certain methods with untrusted JSON could lead to modifying objects up the prototype chain, including the global Object. A crafted JSON object passed to a vulnerable method could lead to denial of service or data injection, with various consequences.
Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes.
Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only "named curves" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low.
In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an "exotic" curve encoding.
The affected APIs include: ECGROUPnewcurveGF2m(), ECGROUPnewfromparams(), and various supporting BNGF2m() functions.
Applications working with "exotic" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
A vulnerability was found in Infinispan before version 10.0.0 Final. The invokeAccessibly method from the public class ReflectionUtil allows any application class to invoke private methods in any class with Infinispan's privileges.
Summary When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash.
Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team <ecosystem@trailofbits.com>
Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime.
Severity CVE-2024-7254 High CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker.
Proof of Concept For reproduction details, please refer to the unit tests (Protobuf Java LiteTest and CodedInputStreamTest) that identify the specific inputs that exercise this parsing weakness.
Remediation and Mitigation We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: protobuf-java (3.25.5, 4.27.5, 4.28.2) protobuf-javalite (3.25.5, 4.27.5, 4.28.2) protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2)
Applications that use UriComponentsBuilder in Spring Framework to parse an externally provided URL (e.g. through a query parameter) AND perform validation checks on the host of the parsed URL may be vulnerable to a open redirect https://cwe.mitre.org/data/definitions/601.html attack or to a SSRF attack if the URL is used after passing validation checks.
This is the same as CVE-2024-22243 https://spring.io/security/cve-2024-22243 , but with different input.
A flaw was found in jackson-databind 2.x. The interaction between serialization gadgets and typing is mishandled. 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. The interaction between serialization gadgets and typing is mishandled. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
FasterXML jackson-databind 2.x before 2.9.10.6 mishandles the interaction between serialization gadgets and typing, related to br.com.anteros.dbcp.AnterosDBCPDataSource (aka Anteros-DBCP).
A flaw was found in jackson-databind 2.x in versions prior to 2.9.10.5. 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.5. 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.5. The interaction between serialization gadgets and typing is mishandled. 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.5. FasterXML jackson-databind 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 before 2.9.10.7 and 2.6.7.5. FasterXML 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.