GHSA-jfh8-c2jp-5v3q CVE-2021-44228
Remote code injection in Log4j
Critical
Known exploited
Maven
- Severity
- 10.0 / 10
- Critical · CVSS 3.1
- Exploit chance (EPSS)
- 100.00%
- Chance of exploitation in the next 30 days. Higher than 100.00% of scored vulnerabilities.
- Known exploited
- Yes
- In CISA's catalog since Dec 10, 2021
- Weakness
- CWE-20 Improper Input Validation
- CWE-400 Uncontrolled Resource Consumption
- CWE-502 Deserialization of Untrusted Data
- CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
- Fix
- Available
- 2 packages have a fixed version
Exploited in the wild. Apache Log4j2 Remote Code Execution Vulnerability (Apache Log4j2). Required action: For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. Temporary mitigations using one of the measures provided at https://www.cisa.gov/uscert/ed-22-02-apache-log4j-recommended-mitigation-measures are only acceptable until updates are available. Due for U.S. federal agencies by Dec 24, 2021. Known to be used in ransomware campaigns.
Description
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.
Affected versions
Maven
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
org.apache.logging.log4j:log4j-core Maven → 2.15.0
- maven
<dependency><groupId>org.apache.logging.log4j</groupId><artifactId>log4j-core</artifactId><version>2.15.0</version></dependency>- gradle
implementation("org.apache.logging.log4j:log4j-core:2.15.0")
org.ops4j.pax.logging:pax-logging-log4j2 Maven → 1.9.2
- maven
<dependency><groupId>org.ops4j.pax.logging</groupId><artifactId>pax-logging-log4j2</artifactId><version>1.9.2</version></dependency>- gradle
implementation("org.ops4j.pax.logging:pax-logging-log4j2:1.9.2")
Severity breakdown
CVSS 3.1 10.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- High
- Exploit maturity
- H
Weakness
CWE-20: Improper Input Validation
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
How to prevent it
- Architecture and Design: Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
- Architecture and Design: Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
- Architecture and Design, Implementation: Understand all the potential areas where untrusted inputs can enter the product, including but not limited to: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
- Implementation: When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
- Implementation: Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
- Implementation: Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
- Implementation: When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
CWE-400: Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource.
How to prevent it
- Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
- Implementation: Ensure that all failures in resource allocation place the system into a safe posture.
CWE-502: Deserialization of Untrusted Data
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
How to prevent it
- Architecture and Design, Implementation: If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
- Implementation: Explicitly define a final object() to prevent deserialization.
- Architecture and Design, Implementation: Make fields transient to protect them from deserialization. An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.
- Implementation: Avoid having unnecessary types or gadgets (a sequence of instances and method invocations that can self-execute during the deserialization process, often found in libraries) available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
- Architecture and Design, Implementation: Employ cryptography of the data or code for protection. However, it's important to note that it would still be client-side security. This is risky because if the client is compromised then the security implemented on the client (the cryptography) can be bypassed.
- Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
The product constructs all or part of an expression language (EL) statement in a framework such as a Java Server Page (JSP) using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended EL statement before it is executed.
How to prevent it
- Architecture and Design: Avoid adding user-controlled data into an expression interpreter when possible.
- Implementation: If user-controlled data must be added to an expression interpreter, one or more of the following should be performed: Validate that the user input will not evaluate as an expression Encode the user input in a way that ensures it is not evaluated as an expression
- System Configuration, Operation: The framework or tooling might allow the developer to disable or deactivate the processing of EL expressions, such as setting the isELIgnored attribute for a JSP page to "true".
References
Advisories
Fixes and patches
Packages
Other links
- github.com/tangxiaofeng7/apache-log4j-poc
- logging.apache.org/log4j/2.x/changes-report.html
- logging.apache.org/log4j/2.x/manual/lookups.html
- issues.apache.org/jira/browse/LOG4J2-3198
- issues.apache.org/jira/browse/LOG4J2-3201
- logging.apache.org/log4j/2.x/manual/migration.html
- logging.apache.org/log4j/2.x/security.html
- packetstormsecurity.com/files/165225/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
- openwall.com/lists/oss-security/2021/12/10/1
- openwall.com/lists/oss-security/2021/12/10/2
- openwall.com/lists/oss-security/2021/12/10/3
- psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0032
- issues.apache.org/jira/browse/LOG4J2-3214
- oracle.com/security-alerts/alert-cve-2021-44228.html
- openwall.com/lists/oss-security/2021/12/13/1
- openwall.com/lists/oss-security/2021/12/13/2
- issues.apache.org/jira/browse/LOG4J2-3221
- cert-portal.siemens.com/productcert/pdf/ssa-661247.pdf
- lists.debian.org/debian-lts-announce/2021/12/msg00007.html
- twitter.com/kurtseifried/status/1469345530182455296
- debian.org/security/2021/dsa-5020
- packetstormsecurity.com/files/165260/VMware-Security-Advisory-2021-0028.html
- packetstormsecurity.com/files/165261/Apache-Log4j2-2.14.1-Information-Disclosure.html
- packetstormsecurity.com/files/165270/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
- openwall.com/lists/oss-security/2021/12/14/4
- intel.com/content/www/us/en/security-center/advisory/intel-sa-00646.html
- kb.cert.org/vuls/id/930724
- packetstormsecurity.com/files/165281/Log4j2-Log4Shell-Regexes.html
- packetstormsecurity.com/files/165282/Log4j-Payload-Generator.html
- packetstormsecurity.com/files/165306/L4sh-Log4j-Remote-Code-Execution.html
- packetstormsecurity.com/files/165307/Log4j-Remote-Code-Execution-Word-Bypassing.html
- packetstormsecurity.com/files/165311/log4j-scan-Extensive-Scanner.html
- openwall.com/lists/oss-security/2021/12/15/3
- cert-portal.siemens.com/productcert/pdf/ssa-714170.pdf
- cert-portal.siemens.com/productcert/pdf/ssa-397453.pdf
- cert-portal.siemens.com/productcert/pdf/ssa-479842.pdf
- packetstormsecurity.com/files/165371/VMware-Security-Advisory-2021-0028.4.html
- packetstormsecurity.com/files/165532/Log4Shell-HTTP-Header-Injection.html
- github.com/cisagov/log4j-affected-db/blob/develop/SOFTWARE-LIST.md
- packetstormsecurity.com/files/165642/VMware-vCenter-Server-Unauthenticated-Log4Shell-JNDI-In…
- packetstormsecurity.com/files/165673/UniFi-Network-Application-Unauthenticated-Log4Shell-Rem…
- oracle.com/security-alerts/cpujan2022.html
- github.com/cisagov/log4j-affected-db
- support.apple.com/kb/HT213189
- bentley.com/en/common-vulnerability-exposure/be-2022-0001
- oracle.com/security-alerts/cpuapr2022.html
- github.com/nu11secur1ty/CVE-mitre/tree/main/CVE-2021-44228
- nu11secur1ty.com/2021/12/cve-2021-44228.html
- packetstormsecurity.com/files/167794/Open-Xchange-App-Suite-7.10.x-Cross-Site-Scripting-Comm…
- packetstormsecurity.com/files/167917/MobileIron-Log4Shell-Remote-Command-Execution.html
- packetstormsecurity.com/files/171626/AD-Manager-Plus-7122-Remote-Code-Execution.html
- msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2
- security.netapp.com/advisory/ntap-20211210-0007
- lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/M5CSV…
- lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VU57U…
- packetstormsecurity.com/files/165673/UniFi-Network-Application-Unauthenticated-Log4Shell-Rem…
- packetstormsecurity.com/files/167794/Open-Xchange-App-Suite-7.10.x-Cross-Site-Scripting-Comm…
- packetstormsecurity.com/files/167917/MobileIron-Log4Shell-Remote-Command-Execution.html
- packetstormsecurity.com/files/171626/AD-Manager-Plus-7122-Remote-Code-Execution.html
- sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-…
- seclists.org/fulldisclosure/2022/Dec/2
- seclists.org/fulldisclosure/2022/Jul/11
- seclists.org/fulldisclosure/2022/Mar/23
- tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-…
- cisa.gov/known-exploited-vulnerabilities-catalog
- lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/M5C…
- lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VU5…
- seclists.org/fulldisclosure/2022/Dec/2
- seclists.org/fulldisclosure/2022/Jul/11
- seclists.org/fulldisclosure/2022/Mar/23
- lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/M5C…
- lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VU5…
Timeline
- Added to CISA's Known Exploited Vulnerabilities catalog
- Published
- Remediation due for U.S. federal agencies
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-7rjr-3q55-vv33 Incomplete fix for Apache Log4j vulnerability | Critical Known exploited | Also affects org.apache.logging.log4j:log4j-core |
| GHSA-m665-v7pm-7grj zip: Critical Parser Differential & Security Control Bypass via Dual-Header Inconsistencies (Zip Cloaking) Leading to Arbitrary File Overwrite & RCE | Critical | Same weakness, CWE-20 |
| GHSA-g5ff-637f-6q2m LiteLLM: internal_user_viewer arbitrary local file read via `vertex_ai_credentials` | High | Same weakness, CWE-20 |
| GHSA-h3rc-j82p-2c3h vLLM: Untrusted EPS inputs can trigger denial of service or Ghostscript RCE | High | Same weakness, CWE-20 |
| GHSA-8c8m-p3m8-cjg8 Nodemailer: A nested comment ends early in addressparser, releasing the rest of the comment as a recipient | Medium | Same weakness, CWE-20 |
| GHSA-m943-m63m-w62w Nodemailer: A ";" inside a quoted string or comment ends an address group early in addressparser, turning display text into a recipient | Medium | Same weakness, CWE-20 |
| GHSA-85x2-q946-cp5h Nodemailer: A ">" inside a quoted local part ends an angle-addr early in addressparser, delivering to a domain the header does not name | Medium | Same weakness, CWE-20 |
| GHSA-5hx5-vpf9-5wcv pypdf: Unvalidated JPEG image data loading | Low | Same weakness, CWE-20 |
Credits: ppkarwasz
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor