Skip to content

Latest commit

 

History

History
112 lines (83 loc) · 8.98 KB

mitigations.md

File metadata and controls

112 lines (83 loc) · 8.98 KB

Mitigation Strategies Analysis for apache/logging-log4j2

Mitigation Strategy: Upgrade Log4j 2 Library

  • 1. Mitigation Strategy: Upgrade Log4j 2 Library

    • Description:

      1. Identify Dependencies: Use dependency management tools (Maven: mvn dependency:tree, Gradle, etc.) to find all direct and transitive uses of Log4j 2.
      2. Check Current Version: Determine the exact version(s) of Log4j 2 currently in use.
      3. Identify Latest Secure Version: Refer to the official Apache Log4j 2 security page (https://logging.apache.org/log4j/2.x/security.html) for the latest secure version compatible with your Java environment (Java 6, 7, 8+).
      4. Update Dependency Declarations: Modify your project's build files (e.g., pom.xml, build.gradle) to explicitly require the latest secure version of Log4j 2. Update all instances.
      5. Resolve Conflicts: Address any dependency conflicts. You may need to exclude older, vulnerable versions of Log4j 2 brought in by other libraries and force the use of the newer version.
      6. Rebuild and Test: Rebuild the application and execute comprehensive automated and manual tests. Focus on logging functionality and overall application stability.
      7. Deploy: Deploy the updated application to all environments.
      8. Monitor: Monitor application logs and performance post-deployment.

    • Threats Mitigated:

      • CVE-2021-44228 (Log4Shell): Remote Code Execution (RCE) - Critical Severity. Patched versions remove the vulnerable JNDI lookup functionality.
      • CVE-2021-45046: Denial of Service (DoS) and limited RCE (non-default configurations) - High Severity. Addressed by further updates.
      • CVE-2021-45105: Denial of Service (DoS) - High Severity. Fixed in later versions.
      • Other Vulnerabilities: Upgrading addresses any other known and patched security issues.

    • Impact:

      • CVE-2021-44228: Risk reduced from Critical to Negligible (eliminated).
      • CVE-2021-45046: Risk reduced from High to Negligible.
      • CVE-2021-45105: Risk reduced from High to Negligible.
      • Other Vulnerabilities: Risk significantly reduced.

    • Currently Implemented: Partially. service-a upgraded to 2.17.1. reporting-module remains at 2.14.1.

    • Missing Implementation: Upgrade reporting-module. Verify all third-party libraries use secure Log4j 2 versions.

Mitigation Strategy: Disable JNDI Lookups

  • 2. Mitigation Strategy: Disable JNDI Lookups

    • Description:

      1. Identify Deployment Method: Determine how the application is started (standalone JAR, WAR, container, etc.).
      2. JVM Argument (Preferred): Add -Dlog4j2.formatMsgNoLookups=true to the Java command line. This is the most reliable method. The specific steps depend on the deployment:
        • Standalone JAR: Modify the startup script.
        • Application Server (Tomcat, etc.): Update server configuration files (e.g., setenv.sh, catalina.properties).
        • Docker: Add to JAVA_OPTS in the Dockerfile or docker-compose file.
      3. Environment Variable (Alternative): Set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true. Less reliable than JVM arguments.
      4. Programmatic Setting (Least Reliable): As a last resort, attempt: System.setProperty("log4j2.formatMsgNoLookups", "true"); in the application code. This may be too late to be effective.
      5. Verification: Crucially, verify the setting is active. Check logs for messages indicating lookups are disabled, or attempt a JNDI lookup (in a controlled environment) to confirm failure.
      6. Apply Consistently: Ensure this setting is applied to all application instances and dependencies.

    • Threats Mitigated:

      • CVE-2021-44228 (Log4Shell): Remote Code Execution (RCE) - Critical Severity. Disables the core vulnerable functionality.
      • CVE-2021-45046: DoS and limited RCE - High Severity. Also mitigated.

    • Impact:

      • CVE-2021-44228: Risk reduced from Critical to Low (significantly reduced, but not eliminated if misconfigured or if older Log4j 2 versions don't fully respect the setting).
      • CVE-2021-45046: Risk reduced from High to Low.
      • CVE-2021-45105: Not directly mitigated.

    • Currently Implemented: No.

    • Missing Implementation: Implement as a defense-in-depth measure across all components, especially reporting-module. Add the JVM argument to startup scripts.

Mitigation Strategy: Remove JndiLookup Class

  • 3. Mitigation Strategy: Remove JndiLookup Class

    • Description:

      1. Locate JAR Files: Find all JAR files containing the Log4j 2 core library (log4j-core-*.jar).
      2. Backup: Always create backups of the original JAR files before modification.
      3. Remove the Class: Use the zip command (or equivalent on Windows) to delete the JndiLookup.class file: 
        zip -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
        Repeat for every relevant JAR file.
      4. Replace Original JAR: Replace the original log4j-core-*.jar files with the modified versions.
      5. Test Thoroughly: Extensively test the application to ensure correct functionality. Focus on any areas that might have (unusually) used JNDI.
      6. Document: Clearly document this non-standard modification.

    • Threats Mitigated:

      • CVE-2021-44228 (Log4Shell): Remote Code Execution (RCE) - Critical Severity. Removes the vulnerable code entirely.
      • CVE-2021-45046: DoS and limited RCE - High Severity. Also mitigated.

    • Impact:

      • CVE-2021-44228: Risk reduced from Critical to Negligible (eliminated).
      • CVE-2021-45046: Risk reduced from High to Negligible.
      • CVE-2021-45105: Not directly mitigated.

    • Currently Implemented: No. Last resort.

    • Missing Implementation: Consider for reporting-module only if upgrading is impossible. Upgrading is strongly preferred.

Mitigation Strategy: Limit Logging of User-Controlled Input (Log4j2 configuration)

  • 4. Mitigation Strategy: Limit Logging of User-Controlled Input (Log4j2 configuration)

    • Description:

      1. Review Log4j2 Configuration: Examine your log4j2.xml (or other configuration file format) to identify patterns and appenders.
      2. Modify Patterns: Adjust the patterns used in your appenders (especially PatternLayout) to avoid logging potentially dangerous input directly. For example, instead of logging the entire message (%m), consider logging only specific, sanitized parts of the message. Use custom message objects or structured logging to control what gets logged.
      3. Use Filters: Implement Log4j 2 filters to selectively filter out log events based on their content. You could create a custom filter that checks for potentially malicious patterns (like ${jndi:) and prevents those events from being logged. This is more robust than just modifying the pattern.
      4. Context Map Filtering: If you're using the Thread Context Map (MDC), be very careful about what you put in the MDC, as it's often included in log messages. Avoid putting user-supplied data directly into the MDC.
      5. Test Configuration Changes: After making any changes to your Log4j 2 configuration, thoroughly test to ensure that logging still works as expected and that the changes effectively mitigate the risk.

    • Threats Mitigated:

      • CVE-2021-44228 (Log4Shell): Remote Code Execution (RCE) - Critical Severity. Reduces the attack surface by controlling what data is processed by Log4j 2's vulnerable components.
      • Other Injection Attacks: Can help mitigate other injection attacks that might leverage logging.

    • Impact:

      • CVE-2021-44228: Risk reduced from Critical to High (reduces the likelihood of triggering the vulnerability, but doesn't eliminate it).
      • Other Injection Attacks: Reduces risk.

    • Currently Implemented: Partially. Some patterns have been reviewed, but a comprehensive review of the Log4j 2 configuration and the implementation of filters are needed.

    • Missing Implementation: A full review of log4j2.xml is required. Custom filters should be implemented to specifically check for and block potentially malicious log messages. The use of the MDC needs to be carefully reviewed.