Skip to content

Latest commit

 

History

History
53 lines (40 loc) · 5.54 KB

mitigations.md

File metadata and controls

53 lines (40 loc) · 5.54 KB

Mitigation Strategies Analysis for apache/logging-log4j2

Mitigation Strategy: Upgrade Log4j2 Version

Description:

  1. Identify Log4j2 Dependencies: Use dependency management tools (like Maven, Gradle, or dependency-check) to identify all direct and transitive dependencies on log4j-core in your project.
  2. Determine Current Version: Check the version of log4j-core being used in your project's dependencies.
  3. Identify Target Version: Consult the official Apache Log4j security advisories and release notes to determine the latest patched and stable version (currently 2.17.1 or later for Log4Shell and related issues).
  4. Update Dependency Management Files: Modify your project's pom.xml (Maven), build.gradle (Gradle), or similar dependency files to specify the target Log4j2 version. Ensure you update all relevant dependencies that might pull in older versions transitively.
  5. Rebuild and Redeploy: Rebuild your application to incorporate the updated Log4j2 library. Thoroughly test the application in development, staging, and production environments to ensure compatibility and stability after the upgrade.
  6. Verify Upgrade: After deployment, verify that the application is indeed using the upgraded Log4j2 version. This can be done by checking application logs or using dependency analysis tools in the deployed environment.

List of Threats Mitigated:

  • Remote Code Execution (RCE) - Critical: Log4Shell (CVE-2021-44228), CVE-2021-45046, CVE-2021-45105, CVE-2021-44832. These vulnerabilities allow attackers to execute arbitrary code on the server by exploiting flaws within Log4j2's processing of log messages. Severity is critical as it allows full system compromise.
  • Denial of Service (DoS) - High: CVE-2021-45046, CVE-2021-45105. Certain vulnerabilities in Log4j2 can lead to DoS by causing infinite recursion or uncontrolled resource consumption during log processing. Severity is high as it can disrupt application availability.
  • Information Disclosure - Medium: While less direct, RCE vulnerabilities in Log4j2 can be leveraged for information disclosure by attackers gaining code execution and accessing sensitive data. Severity is medium as it depends on the attacker's actions after exploitation.

Impact:

High. Upgrading to the latest patched version completely mitigates the known critical RCE and DoS vulnerabilities addressed in those versions within Log4j2 itself. It is the most effective and recommended solution directly targeting Log4j2 vulnerabilities.

Currently Implemented:

[Specify if implemented and where, e.g., Yes, implemented in production and staging environments.]

Missing Implementation:

[Specify where missing, e.g., Development environment needs to be updated, or N/A if fully implemented.]

Mitigation Strategy: Disable JNDI Lookup Functionality in Log4j2

Description:

  1. Choose Method: Select the appropriate method based on your Log4j2 version (2.10 to 2.14.1 or 2.10 to 2.16).
    • System Property/Environment Variable (Versions 2.10 to 2.14.1):
      • Set the system property log4j2.formatMsgNoLookups to true when starting the application (e.g., -Dlog4j2.formatMsgNoLookups=true). This instructs Log4j2 to ignore message lookups.
      • Alternatively, set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true in the application's deployment environment. This achieves the same effect as the system property.
    • Remove JndiLookup Class (Versions 2.10 to 2.16):
      • Locate the log4j-core-*.jar file in your application's dependencies.
      • Use a zip utility (like zip or jar) to remove the org/apache/logging/log4j/core/lookup/JndiLookup.class file from the JAR archive. This physically removes the vulnerable JNDI lookup capability from Log4j2.
      • Caution: This is a more invasive workaround and requires careful testing to ensure no unintended side effects on Log4j2 functionality.
  2. Redeploy Application: Redeploy your application with the chosen JNDI lookup disabling method applied.
  3. Verify Mitigation: Test the application to confirm that JNDI lookups are effectively disabled within Log4j2. You can attempt to trigger a JNDI lookup (e.g., by logging a string containing ${jndi:ldap://...}) and verify that it is not processed by Log4j2.

List of Threats Mitigated:

  • Remote Code Execution (RCE) - Critical: Log4Shell (CVE-2021-44228), CVE-2021-45046 (partially mitigated). Disabling JNDI lookup directly prevents the exploitation of these vulnerabilities through JNDI injection within Log4j2's message formatting.
  • Information Disclosure - Medium: Indirectly mitigates information disclosure risks associated with RCE vulnerabilities in Log4j2 by preventing the initial exploitation vector.

Impact:

Medium to High. Effectively mitigates the primary RCE vulnerability related to JNDI lookups in vulnerable Log4j2 versions. However, it's a workaround and not a complete solution like upgrading. It addresses the specific JNDI lookup vulnerability in Log4j2 but might not protect against all future vulnerabilities in Log4j2 or other attack vectors.

Currently Implemented:

[Specify if implemented and where, e.g., Yes, system property -Dlog4j2.formatMsgNoLookups=true is set in production.]

Missing Implementation:

[Specify where missing, e.g., Staging environment still needs this property, or N/A if not used as upgrade is implemented.]