Are you a sysadmin who managed to get your Log4Shell mitigations done in time for the US Government’s cybersecurity deadline of 24 December 2021?
If so, you may have enjoyed a Christmas mini-vacation along with much of the rest of the world…
…only to return to the fray this week and find that the Apache Log2j team just put out the fourth patch in what you might call the Log4Shell Vulnerability Saga.
The newly discovered bug is CVE-2021-44832, patched in Log4j 2.17.1, announced on 2021-12-28 (yesterday at the time of writing).
“Once more,” dear friends, in the words famously given to King Henry V by the Bard of Avon.
Fortunately, for all the understandable publicity this fourth flaw has received, and for all that we urge you to patch it promptly anyway, this bug is currently only dubbed Moderate.
This one doesn’t seem to be directly and easily exploitable like the original CVE-2021-44228 hole that gave rise to the name Log4Shell in the first place.
The saga so far
To summarise the saga so far, starting on about 09 December 2021:
- News breaks of an easy-to-abuse “feature” in the Apache Log4j logging code. What most programmers shrugged off as simple variable substitution in logging data (e.g. turning
${java:version}into a text string describing the Java version) turned out to allow attackers to hide dangerous commands in data from outside, such as injecting instructions for leaking secret data or downloading malicious code. - Organisations around the world realise the buggy code is very widespread. Even businesses that didn’t consider themselves Java shops found Java apps scattered all over their networks. Log4j unexpectedly turned out to be buried in many of these apps.
- The message sinks in that this bug can be exploited even deep inside a network. Running non-Java servers at the network edge doesn’t remove the risk. Any internal server to which untrusted data (e.g. a telephone number or a postcode) gets sent for processing could be at risk if it logs that data. And many business-logic apps create copious logs, often with good reason, such as for audit or compliance purposes.
- Apache rapidly publishes Log4j 2.15.0, fixing the primary security hole. For those servers where change control stood in the way of applying the patch (apparently without irony given that the same change control process presumably waved through the vulnerable code many years ago), Apache provided handy run-time mitigations to suppress the dangerous behaviour.
- Attacks surge, including many from self-styled researchers “trying to help”. Because this bug was originally a feature, it could be exploited with ease, so anyone who wanted to get involved could give it a go. Thousands, perhaps even millions, did, often without overtly malicious intent. But amid the cybersecurity smoke of unhelpful “research” were numerous genuine fires started by cybercriminals stealing data or implanting malware such as cryptominers and ransomware.
- Apache digs deeper into the code and finds a further flaw. Log4j quickly gets a second update to 2.16.0.
- Apache finds a third flaw that brings us version 2.17.0. We advised sysadmins who were part-way through upgrading to 2.16.0 or 2.15.0 simply to carry on patching, but using 2.17.0 for their as-yet unpatched systems. Better to have all of your systems at 2.15.0 or greater as soon as you could, and then go back and “top up” the 2.15.0 and 2.16.0 servers later, than to risk leaving some servers completely unpatched for longer.
- The US Government sets 24 December 2021 as a must-patch deadline. With Christmas Day and Boxing Day 2021 landing on Saturday and Sunday respectively, creating a weekend-plus-family-holiday double play in much of the world, CISA decides to set the proverbial Night Before Christmas as the deadline for the US public sector to roll out its patches.
Flaw the fourth
This new, fourth flaw was reported just after the Christmas 2021 weekend, on 2021-12-28.
Fortunately, in Apache’s words:
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
RCE, of course, is about the worst sort of cybersecurity hole you’ll experience, because it typically means that an outsider can poke an unexpected program into your computer without so much as a by-your-leave.
An RCE attack might inject an untrusted app, poke a binary fragment of machine code into memory, or sneakily offer up an unwanted script file…
…and if the attacker succeeds, you’ll run their code unknowingly, without any official Are you sure (Y/N)? prompt or This could harm your computer dialog to tip you off.
But for all that this bug mentions RCE, it isn’t really what the jargon calls an unauthenticated remote execution, where anyone who can interact with your network without logging in first (e.g. by visiting a public-facing website) could trigger the bug.
As Apache mentions, to enable remote execution, an attacker would first need sufficient access to mess with the configuration settings of the vulnerable server or business-logic application.
We suspect that any attackers with enough access to alter server-side configuration settings will have any number of additional ways to compromise your internal apps, systems or network.
In other words, if you are directly at risk of CVE-2021-44832 right now, then updating Log4j 2.17.0 to 2.17.1 is probably neither a necessary nor a sufficient solution to your security problems.
Simply put, don’t just patch to 2.17.1 and think, “Great. Now I can relax until the New Year.”
What to do?
- Patch to Log4j 2.17.1 when you can. There’s no point in skipping this update altogether simply because it’s only rated Moderate.
- If you think that CVE-2021-44832 poses a clear and present danger to your network, patching on its own is not enough. A system that is genuinely vulnerable to malicious outsiders on account of this bug is almost certainly at risk of numerous other attacks, too.
- Review your Log4j configuration settings. Look for unauthorised or unwanted settings that you might not have considered before.
In an earlier article, we proposed revisiting your own usage of Log4j in the near future, and working out whether you genuinely need it in your own software.
If you inherited Log4j without even realising it, as part of the Java “supply chain”, and could readily replace it with something much simpler and less feature-rich, we think that would be a wise choice.
Some commenters said we were being unrealistic or going over the top by saying this, claiming that we were underestimating the complex logging needs of the average business app.
But we’re going to suggest, once again, that if you have found Log4j in your ecosystem recently, especially on servers where you didn’t even know it was there, that you should ask yourself the question, “Do I genuinely need a multi-megabyte logging toolkit consisting of close to half a million lines of source code, or would something much more modest and easier to review do at least as well?”
That’s not a criticism of Apache; it’s merely a reminder that inherited security problems such as Log4Shell are often the unexpected side-effect of a cybersecurity decision made years ago by someone from outside your company whom you’ve never met, and never will.
For all that the original decision might not be your doing, it’s now your responsibility, so reviewing it can hardly be considered controversial or ill-considered!
LEARN HOW THE LOG4SHELL VULNERABILITY WORKS
(If you can’t read the text clearly here, try using Full Screen mode, or watch directly on YouTube. Click on the cog in the video player to speed up playback or to turn on subtitles.)