Patching Log4j to version 2.17.1 can probably wait

A number of security professionals say that the latest vulnerability in Apache Log4j, disclosed on Tuesday, does not pose an increased security risk for the majority of organizations. As a result, for many organizations that have already patched to version 2.17.0 of Log4j, released December 17, it should not be necessary to immediately patch to version 2.17.1, released Tuesday.

While the latest vulnerability “shouldn’t be ignored,” of course, for many organizations it “should be deployed in the future as part of usual patch deployment,” said Ian McShane, field chief technology officer at Arctic Wolf, in comments shared by email with VentureBeat.

Casey Ellis, founder and chief technology officer at Bugcrowd, described it as a “weak sauce vulnerability” and said that its disclosure seems more like a marketing effort for security testing products than an “actual effort to improve security.”

Patching woes

The disclosure of the latest vulnerability comes as security teams have been dealing with one patch after another since the initial disclosure of a critical remote code execution (RCE) flaw in the widely used Log4j logging software on December 9.

The latest vulnerability appears in the Common Vulnerabilities and Exposures (CVE) list as 2021-44832, and has a severity rating of “medium” (6.6). It enables “an attacker with permission to modify the logging configuration file [to] construct a malicious configuration,” according to the official description.

However, for teams that have been working nonstop to address Log4j vulnerabilities in recent weeks, it’s important to understand that the risks posed by the latest vulnerability in Log4j are much lower than the previous flaws—and may not be a “drop everything and patch” moment, according to security professionals. While possible that an organization might have the configurations required for exploiting CVE-2021-44832, this would in fact be an indicator of a much larger security issue for the organization.

The latest vulnerability is technically an RCE, but it “can only be exploited if the adversary has already gained access through another means,” McShane said. By comparison, the initial RCE vulnerability, known as Log4Shell, is considered trivial to exploit and has been rated as an unusually high-severity flaw (10.0).

A niche issue

The latest Log4j vulnerability requires hands-on keyboard access to the device running the component, so that the threat actor can edit the config file to exploit the flaw, McShane said.

“If an attacker has admin access to edit a config file, then you are already in trouble—and they haven’t even used the exploit,” he said. “Sure, it’s a security issue—but it’s niche. And it seems far-fetched that an attacker would leave unnecessary breadcrumbs like changing a config file.”

Ultimately, “this 2.17.1 patch is not the critical nature that an RCE tag could lead folks to interpret,” McShane said.

Indeed, Ellis said, the new vulnerability “requires a fairly obscure set of conditions to trigger.”

“While it’s important for people to keep an eye out for newly released CVEs for situational awareness, this CVE doesn’t appear to increase the already elevated risk of compromise via Log4j,” he said in a statement shared with VentureBeat.

Overhyping?

In a tweet Tuesday, Katie Nickels, director of intelligence at Red Canary, wrote of the new Log4j vulnerability that it’s best to “remember that not all vulnerabilities are created equally.”

“Note that an adversary *would have to be able to modify the config* for this to work…meaning they already have access somehow,” Nickels wrote.

Wherever RCE is mentioned in relation to the latest vulnerability, “it needs to be qualified with ‘where an attacker with permission to modify the logging configuration file’ or you are overhyping this vuln,” added Chris Wysopal, cofounder and chief technology officer at Veracode, in a tweet Tuesday. “This is how you ruin relationships with dev teams.”

Log4j 2.17 RCE CVE-2021-44832 in a nutshell pic.twitter.com/GPaHcDHlj0

— Florian Roth ⚡️ (@cyb3rops) December 28, 2021

“In the most complicated attack chain ever, the attacker used another vuln to get access to the server, then got CS running, then used CS to edit the config file/restart the service to then remotely exploit the vuln,” tweeted Rob Morgan, founder of Factory Internet. “Yep, totally the best method!”

A widespread vulnerability

Many enterprise applications and cloud services written in Java are potentially vulnerable to the flaws in Log4j. The open source logging library is believed to be used in some form — either directly or indirectly by leveraging a Java framework — by the majority of large organizations.

Version 2.17.1 of Log4j is the fourth patch for vulnerabilities in the Log4j software since the initial discovery of the RCE vulnerability, but the first three patches have been considered far more essential.

Version 2.17.0 addresses the potential for denial of service (DoS) attacks in version 2.16, and the severity for the vulnerability has been rated as high.

Version 2.16, in turn, had fixed an issue with the version 2.15 patch for Log4Shell that did not completely address the RCE issue in some configurations. The initial vulnerability could be used to enable remote execution of code by unauthenticated users.