Skip to content

Log4J 2.17.1 - Lower Risk, Patch When You Can

    
Log4J 2.17.1 - Lower Risk, Patch When You Can

The season of Log4J vulnerabilities continues with a new Log4J 2.17.1 released on December 28, however the risk is lower than others. Teams that have not patched previous Log4J updates must do so immediately, teams that have been diligent on patching should simply factor this patch for CVE-2021-44382 into their regular patch cycles.

What happened: Attackers with privileged access can modify log4j configuration to launch an attack

A CVE was filed disclosing that certain log4j versions (including version 2.17) were vulnerable to a remote code execution (RCE) if an attacker was able to modify the log4j configuration file. Specifically, the attacker will need to point the configuration file to a remote URI data source to load arbitrary Java code. 

Risk: Medium - Requires an attacker to already have control over the application

While the vulnerability is classified as a Remote Code Execution (RCE), it requires an attacker to modify server-side files that make up the application’s logging configuration. The default configuration of log4j is not vulnerable to this attack and most users will not be affected.

As a general rule, if attackers can modify arbitrary and sensitive files on your server-side system, they already have enough access to not need an exploit. Usually this type of exploit is a custom vulnerability or Remote Command Execution or Path Traversal. While the Apache Software Foundation has been under heavy scrutiny lately and patched this CVE, people who are affected by it most likely have one of these vulnerabilities already. Remote users should not be able to change your application’s configuration files - if they can, patching log4j will not prevent them from changing other server-side files in your application and doing something else.

Action: Patch when possible

While you should patch this, you don’t need to rush like you did with the earlier Remote Code Execution flaws that were accessible everywhere.

Going Forward: Maintain a general patch cadence

Teams should work on maintaining a general patch upgrade cadence as part of good hygiene. Update libraries from third parties on each release, update vendor software with their security patches, and so on.

 

Erik Costlow, Director of Developer Relations

Erik Costlow, Director of Developer Relations

Erik Costlow was Oracle’s principal product manager for Java 8 and 9, focused on security and performance. His security expertise involves threat modeling, code analysis, and instrumentation of security sensors. He is working to broaden this approach to security with Contrast Security. Before becoming involved in technology, Erik was a circus performer who juggled fire on a three-wheel vertical unicycle.