DoS bugs and Patches- We answer your questions

Questions are swirling about the log4j vulnerability. We wanted to clarify two of the recent ones that our clients have been asking.  Who better to get our answers from but our Co-Founder and CTO, Jake Williams. Here are the answers we gave our clients.

Is there a Denial-of-Service bug that will kill the running application?

This vulnerability was discovered because of additional attention paid to log4j by researchers after the original remote code execution bug was disclosed. We shouldn’t be surprised that additional vulnerabilities have been discovered in log4j, given the increased specific focus on the library. However, organizations should understand that this is only a denial of service (DoS) vulnerability.  It does not offer the threat actor any ability to steal data or implant a backdoor.

Similar to log4j, this summer, the original PrintNightmare vulnerability disclosure led to the discovery of multiple additional distinct vulnerabilities. The discovery of other vulnerabilities in log4j shouldn’t cause concern about the security of log4j itself. If anything, log4j is more secure because of the additional attention paid by researchers. The log4j code has been reviewed by orders of magnitude more researchers than any custom application deployed by an organization. In the coming weeks, the updated version of the log4j library will almost certainly be more secure than the code that uses it.

Is there a bypass to the original 2.15.0 patches?

While researchers have discovered a bypass to some fixes employed in log4j the 2.15.0 patches, unlike the original disclosures, this vulnerability is not exploitable in most configurations. This bypass should not concern teams that have already updated to 2.16.0. Even for those organizations that already patched to 2.15.0, this bypass is probably not exploitable in their applications. We continue to recommend limiting outbound communication on potentially vulnerable servers to only known-good destinations as that prevents code execution in both the originally disclosed vulnerability and this bypass.

Should I be concerned about a log4j worm?

While it’s certainly possible that threat actors might create a worm that abuses the log4j vulnerabilities, the immediate damage will likely be more limited. It’s not likely that it would be like worms of the past like WannaCry, NotPetya, or many previous worms that abuse system-level processes. The majority of servers vulnerable to Log4Shell are running the vulnerable process with very limited permissions. That’s not to say there’s no impact in those cases, only that elevation would be required. And this means additional logic the threat must embed in the worm. Now we’re talking about a worm with multiple exploits and additional logic, raising the stakes for threat actors.

In many cases, a worm exploiting Log4Shell would not be able to achieve persistence across process restarts. Additionally, because many vulnerable processes don’t have significant filesystem permissions, we should be less worried about ransomware payloads. A malicious process can’t encrypt what it can’t write in the first place.

For more useful information on the Log4j vulnerability, check out our Actionable Recommendations for Log4Shell/Log4j (Without the Hype).