Update: Log4Shell RCE Zero-Day—Reactions and Recriminations
Last week’s critical bug in Log4j still reverberates ’round the racks. Disbelief quickly gave way to denial and bargaining.
Now we seem to be in the guilt and anger phases. Much of the ire is directed at guilty Java programmers. As the details of the bug get teased out, it only adds fuel to the “Java is a steaming pile” fire.
Next up: Depression and acceptance. In today’s SB Blogwatch, we wave goodbye to Java.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Mon capitaine.
Java Considered Harmful
What’s the craic? In case you’ve been living under a rock, Teri Robinson reports—“Log4j Threatens, Well, Everything”:
“Hand attackers full server control”
It doesn’t get much worse than this. … Log4j promises to leave a trail of damage and destruction in its wake, even for those who quickly take action.
…
The Log4j2 Java logging library, home to the newly discovered zero-day exploit, is ubiquitous and the vulnerability, CVE-2021-44228, also known as Log4Shell, is easy to exploit. … The exploit, for which a proof-of-concept (POC) was posted on GitHub, could hand attackers full server control simply through logging a certain string.
And Dan Goodin adds—“The Log4Shell 0-day, four days on”:
“Update Log4J”
Log4Shell is the name given to a critical zero-day vulnerability that surfaced on Thursday when it was exploited in the wild in remote-code compromises. … In the four days since … the list of cloud services affected reads like a who’s who of the biggest names on the Internet. Threat analysts and researchers are still assessing the damage.
…
The source of the vulnerability was Log4J … an open source Java-based logging tool available from Apache. It has the ability to perform network lookups using the Java Naming and Directory Interface to obtain services from the Lightweight Directory Access Protocol. The end result: Log4j will interpret a log message as a URL, go and fetch it, and even execute any executable payload it contains with the full privileges of the main program.
…
The vulnerability, tracked as CVE-2021-44228, has a severity rating of 10 out of 10. The zero-day had been exploited at least nine days before it surfaced. … Researchers report seeing this critical and easy-to-exploit vulnerability being used to install crypto-mining malware, bolster Linux botnets, and exfiltrate configurations, environmental variables, and other potentially sensitive data from vulnerable servers.
…
The most useful thing the cloud services can do is to update Log4J. But for large enterprises, it’s often not that simple.
But perhaps it’s all the admins’ fault? Adrian Sutton—@AJSutton—certainly thinks so:
“You haven’t applied security updates … for nearly 5 years”
For this log4j issue to result in RCE you need to be using Java 8 (which is EOL in a few months) and not have applied Java security updates for nearly 5 years. … If you’ve updated Java anytime since January 2017 a DoS attack is the worst case scenario.
…
Because there’s a lot of really awful takes floating around from people who clearly haven’t read the actual CVE. … Look at that last sentence: … “Java 8u121 … protects against remote code execution.”
…
And when did Java 8u121 come out you ask? Oh, just January 17, 2017. … If you haven’t applied security updates on your systems for nearly 5 years, I strongly suspect this is not the first or only remote code exploit you’re vulnerable to.
Is that entirely fair? Free Wortley, Chris Thompson and Forrest Allison are like a box of chocolates—“Guide: How To Detect and Mitigate”:
“Painful experience”
Be careful what Log4Shell advice you trust online. … Some of this information is outdated or wrong and will leave you vulnerable if you follow it! … Simply updating Java isn’t (likely) sufficient long-term. … We believe it’s likely only a matter of time before all Java versions, even current Java 11 versions, are impacted [because] it’s still possible to instantiate local classes on the server.
…
This vulnerability affects anybody who’s using the log4j packages (log4j-core, log4j-api, etc.). That means it’s primarily Java, but other languages like Scala, Groovy, or Clojure are also impacted.
…
Almost all versions of log4j version 2 are affected. … Version 1 of log4j is vulnerable to other RCE attacks (like CVE-2019-17571), and if you’re using it you need to migrate to 2.15.0. … The last few days have been a painful experience for nearly every tech company out there.
But why would anyone be running five-year-old Java? Here’s kriston pointing the finger:
You can blame Oracle’s Java license fiasco over the past five years. Until recently, nobody could be completely sure if they were legally allowed to upgrade past JRE 8.
You can say that again. Androgynous Cupboard is excoriating:
“A steaming pile of ****”
The issue is that a logging framework—which must be … simple, stable, predictable, beyond reproach—is doing things which invoke a class loading operation. … It’s a fairly typical Apache Java project: everything put in, nothing taken out, keep throwing interfaces at it until it works—design be damned, we’ll crush the problem to death.
…
Programmers of the world: … Limit your scope. Do one thing well, it’s enough. … This is a steaming pile of ****.
Specifically, though? What’s wrong with it? sarusa counts the ways:
“You never interpret user data, ever”
It’s a consequence of two things. First, log4j has a bunch of things you can include in the logging, of the format ${type:parameter}. … At some point someone added … JNDI—a bloated enterprisey monstrosity.
…
As soon as you add the ${jndi:} bit you get access to parts of it that make no sense for logging like ‘fetch and execute remote code’. It’s like you needed a canoe to cross a pond, but you just dropped in a nuclear aircraft carrier because it was handy. What could go wrong?
…
The second part was the absolutely boneheaded decision by log4j to look for and execute the ${type:parameter} in everything being logged, including random user data. You never interpret user data, ever. … Now you’ve handed everyone … the keys to your nuclear aircraft carrier.
So nuke Java from orbit? Somervillain sounds slightly more nuanced:
“Legitimate reason to complain”
Logging in Java is embarrassingly FUBAR. … The native solution is garbage, so we need a million libraries to log debugging statements, include slf4j—a weird abstraction for all those people who love switching between log4j vs log4j2 vs. logback. And every 5 years, the logging framework du jour has to change.
…
Any time you hear someone complain about Java, they’re a clueless moron who is complaining about a bad applet or JWT/Swing experience they had 20 years ago. But sometimes Java does give them a legitimate reason to complain, and the logging situation is definitely one of those.
Meanwhile, this Anonymous Coward ain’t sitting on any fences:
Java needs to die a fast but still painful death. It’s a convoluted, *****y mess.
And Finally:
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
Image sauce: Yuichi Sakuraba (cc:by-nc)
