Log4j RCE: Emergency patch issued to plug critical auth-free code execution hole in widely used logging utility An unauthenticated remote code execution vulnerability in Apache's Log4j Java-based logging tool is being actively exploited, researchers have warned after it was used to execute code on Minecraft servers. Infosec firm Randori summarised the vuln in a blog post, saying: "Effectively, any scenario that allows a remote …
For anyone not paying attention, this is a steaming pile of shit.
Forget the bug itself. The issue is that a logging framework which must be - above all other APIs - simple, stable, predictable, beyond reproach - is doing things which invoke a class loading operation. It's come as a surprise to me that they would do this, even though I've never understood the love for Log4J . 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 under the size of the API. Programmers of the world, listen to me: limit your scope. Do one thing well, it's enough.
Once again, the scientists were so enthralled with the fact that they could, they never stopped to think if they should...
The object you're logging is, by definition, in a class that's already loaded. And if you're logging to a file, for example, you're going to use the system classloader to load java.io.FileOutputStream. That's how Java works.
This is different as it involves a loading a class from a URL. That's behaviour I would not expect from a logging framework, so I didn't look for it. Neither did anyone else, apparently. It's not called the "Loggging and network class loading framework for Java".
I don't know much about Log4j, specifically, but there's always a danger that the more "pluggable" you make your framework the greater the danger of plugging in an exploit.
However, the bit I find surprising is that news of JNDI exploits have been cropping up on a regular basis since at least 2016 [PDF] and that LDAP-related code loading is disabled by default in later versions of the JDK and yet here we are again.
Exactly. As well as your pithy phrase on plugging, I'd add that dependencies leave you dependent. I've been writing Java for 25 years now and I'm well aware of the holes in the language - I've plugged them with code, or lived with them.
What I haven't done is download 900 Jars of unknown scope and add them to my build environment. I hate this aspect of the industry, I really do. There are vast tracts of poorly written code out there with big, trustworthy-sounding names on it ("Apache", "Eclipse") that developers are pulling in in the hope they will solve their problems, but they just create different problems because the API designer has... well, they haven't designed. There's XML everywhere, public methods everywhere, requirements on common-everything.
Every single method in an API is something you have to learn to use it, and when you get an anonymous lambda function calling into a class like this you have no hope of understanding the code. Most of the methods are undocumented, the rest will be deleted in the next release, and Maven is constantly pulling down new versions without your knowledge... I find it simply incredible that people tolerate this.
As an application developer, if you take this approach you build on sand.
Here endeth the rant. I've had quite a week, can you tell?
The main corollary of it all: Java needs to die a fast but still painful death. It's a convoluted, shitty mess. Most of the devs are OK with the paradigm of throwing more code into any project (most of the time without checking the implications of adding it) and creating resource-eating monsters which ultimately enlarge the attack surface.
No. Itt does lead to other kind of issues like the Tesla 500 Error because software becomes a brittle pile of unrelated layer glued somehow one on top of another. It was a philosophy only useful when systems had so little resources you had to chain applications to get the end result and they could only communicate piping data somehow - and error management meant parsing some textual information written somewhere. I see too much software performing too much logging just because it can't trap and process errors throw by some code deep in the stack of calls across many languages, frameworks, and shells.
The gazillion libraries software today use is a corollary of the same issue - software does use too many dependencies, and most of them are used blindly just to save some development time.
most of them are used blindly just to save some development time
I think there's a deeper general problem (I'm not saying it's related to this package) that the presently fashionable software methodology seems to be that you start in front of a screen, possibly with a second individual, and you begin writing code (or by writing a test for the code you have yet to write) without having considered how the code might actually work, or how it might relate to the code that you might write tomorrow.
The idea of "design" has been deprecated and replaced by a process of successive approximation to a working solution ("refactoring") on a piecemeal basis. The blind reuse of random code is just one symptom of this: it isn't seen as being inherently wrong because there can always be another refactoring in which it is replaced - but of course that's someone else's responsibility. Development has been decoupled from responsibility and authority (deliberately as it notionally gives more status to 'elite' programmer bros) and I can't help feeling that we are going to regret it.
Random net quote:
The Waterfall methodology—also known as the Waterfall model—is a sequential development process that flows like a waterfall through all phases of a project (analysis, design, development, and testing, for example), with each phase completely wrapping up before the next phase begins.
But that doesn't work either. It's the getting the "right" simultaneous balance of top down design and bottom up iterative implementation and testing that is the secret sauce.
Human intelligence as we know it is a result of an iterative test and hack process. God is too distracted by playing Minecraft to see the big picture.
Java developers don't think they've completed the job unless they can get a plugin framework, shims, proxies, factories, a domain-specific language and a whole hierarchy of random and badly debugged class loaders into every single product.
It's why the in-memory size of a java.lang.Boolean instance is currently weighing in at 647k on current processors: 1k to hold the boolean value and 646k to hold the plugins, framework and web server.
The enterpriseyness of Java strikes again. You'd assume, that if you passed a string to a logger, it would write that string to a text file somewhere. Not so, with log4j. Apparently[1] it:
1. A ResourceRef overrides the normal JNDI reference behavior with a set of key=value pairs intended to populate a Bean via setters
2. Java stil lets you specify a custom factor, if that factory is in the classpath.
3. BeanFactory works with ResourceRefs to call the setters and populate the new bean.
4. the forceString directive in a ResourceRef lets you override the name of a setter from setFoo to anything you want; when assigning foo it will call that name.
5. the ELProcessor class works as a gadget, since its eval method is a valid bean setter (though named incorrectly).
6. Create a forceString rule to set "x" by calling "eval" - x doesn't even have to be a real field of ELProcessor
7. Try to set x to a string
8. BeanFactory calls ELProcessor.eval() on the string, because forceString makes eval() the setter for x
9. Execute arbitrary EL
Some BeanFactory setter JNDI lookup LDAP evaluator gets involved and fucks up somehow, because obviously it's Java so you can't just write a text string to a file.
[1] https://github.com/drahosj/log4shell_poc
By the way the article states "Whether it was or not, it affects both Log4j and its newer version, Log4j2" - but I'm not sure this is correct, as the lunasec page states it's only Log4j2:
2.0 <= Apache log4j <= 2.14.1
It's also worth noting that if you've upgraded your JVM fairly recently you might not be vulnerable.
JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector.
I think that will get a lot of people off the hook.
Lunasec haven't checked log4j versions below 2.0 as it isn't supported software, and hasn't been for a long time. As I understand it log4j versions below 2.0 might be vulnerable to this, but even if they're not vulnerable to this they're vulnerable to plenty of other things, and they're not getting fixed.
No, the OP is correct.
The capability to load anything via ldap-URLs in logging strings was introduced in log4j 2.0.
Consequently, using log4j 1.x perfectly protects against CVE-2021-44228.
But you are correct in that the 1.x versions have other vulnerabilities, namely https://nvd.nist.gov/vuln/detail/CVE-2019-17571, that is, however, externally exploitable under only very specific circumstances and use cases and was known/handled since early 2020.
Here's the first part of the CVE. It does not specifically exclude 1.x versions.
Also, LDAP isn' t the only attack vector.
It seems that the only "immune" versions would be those without JNDI resolution:
"Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” or by ..."
Yes, always better to write your own version of all the things, so that competent people can ensure system versions are secure and patched against known vulnerabilitys and then your half-thought-out bloated half-functional changing-with-every-release equivalent brings back all the vulnerabilities people fixed and a whole lot of new ones of its own.
Like this one.
Java programmers: like programmers, but not so good.
To test that hypothesis would require well-designed replacements to exist. And the things people write in Java that we are talking about here are designed by Java programmers, so they almost never are candidates.
But are many examples in fact. Who uses CFEngine now (someone must?), and I wonder if Puppet will survive Ansible? Who uses rdist still (again, someone must)?
Who still uses Perl? (I do, but suspect is dying away in face of less line-noisy tools).
And so on.
More that the SysAdmins are the ones left holding the can patching everything up because developers appear incapable of writing secure code.
Security issue - SysAdmin problem they did not see it coming.
Functionality issue - SysAdmin problem because they did not install the latest and greatest piece of unknown supporting tat because, unsurprisingly system availability matters.
Compatibility issue - SysAdmin problem because they needed to remove old, unsupported software or put workarounds in place to stop it from being exploited.
The list goes on but the nuts and bolts is that if anything goes wrong it is the fault of the SysAdmins from any quarter.
Riiiiight.
Like we already don't have enough to do already between planning for capacity upgrades, making sure that old crusty old legacy machine is kept on life support so it can to it's tiny little job of grinding out a company's amount of paychecks on the regular, planning for the replacement of said crusty old dinosaur, dealing with support requests of varying intelligence (or lack thereof), dealing with at least one Project manager who insists on micromanaging every last detail of the project they are working to death, dealing with random cyber attacks from outer Euraisa (or Eastasia, depending on the time of day), managing all the other critical patches, the "ZOMFG PATCH THIS RIGHT NOW!!!!111oneoenoneoen" exploits, re-building the dev boxes because some developer somehow managed to uninstall the UI on it whilst trying to install a patch for their IDE, re-re-building the dev boxes because some developer decides to try and replicate the UI removal bug intentionally, re-re-re-building the dev boxes because the machine got pwned because it was missing a patch, making sure the test lab matches production, and finally dealing with developers who demand root|admin rights on the production servers so they can screw them over as badly as the dev boxes that you just had to rebuild because their code won't run without it.
Will that be all?
systemd is a crawling horror. It is just a part of the ongoing undeclared war by (some of perhaps?) people who make Linux distributions on their users. Is not the only crawling horror: look at polkit say, because ... well, polkit was not written by a person with any understanding if anything, really.
The people who implement and deploy these slime-dripping deformed monsters are not systems administrators. Systems administrators spend their lives trying to understand what material they can use to encase them which is adamant enough that the corrosive goo that drips and sometimes sprays from them does not eat through the hull.
... systemd is a crawling horror. It is just a part of the ongoing undeclared war ...
Indeed ...
To quote another comentard on systemd, here at ElReg:
---
" ... takes root in its host, eats massive quantities of resources as it grows, spreads unchecked into areas unrelated to the initial infection, and refuses to die unless physically removed from the system, all the while doing absolutely nothing of benefit to the host."
---
For the longest time I have been wondering if, to find out who/why, we should not be "following the money", so to speak.
O.
I'm not a Java programmer, so please excuse the naïve question: Is this another example of xkcd: 327: Exploits of a Mom, where inadequate validation and sanitisation of user input leads to untoward results?
No, it's by design. Here's a better writeup, now the dust has settled a bit: https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/.
> Any user input to log4j should have ${ stripped as well as the other usual quotes and squiggles.
Of course you sanitize any input you will subsequently use. But do you REALLY always sanitize all input data before LOGGING it? When a request fails, do you really never log what the raw failed request is?
And you sanitize all the HTTP headers, too, right? Not really though of as user-input, but it is. Do you never use '$' or '{' characters in your random data for user login cookies/tokens? You always drop those if received, right? And you'd never log the fact that you received something invalid, right?
How about not executing it? Can we all agree that executing stuff in a logfile is dumb and all this stuff that goes into log files should be saved literally and never parsed as code to execute?
Jimmy on a pogo stick, that's all the input sanitization you need. Just literal the write to log and move on.
If an effective strings of suitable carefully chosen simple words creates, commands and controls and destroys worlds, to worry about dodgy code injections/viral systemic virtual machine infections is rather bizarre and presents yet another novel exploit field with a practically endless supply of critical vital vulnerabilities to assault with attacks or defend with crack hacks employing and enjoying Alien Instruction.
A simple disturbing question to ask yourself is ........ Can I be immune and uninfected and remain not radically fundamentally affected whenever the masses around me so clearly are smitten?
That’s the new hearts and minds battlefield to comprehensively conquer for those intent on inflicting sufferings and warlike defeats .... in order not to end up as you intend and contend and are content others need to be.
A taste of one’s own medicine is a great leveller upper and AWEsome program downer.
If you manage a large vmware infrastructure you're in for LONG hours in patching all those vmware appliances such as vCenter and vReplication Appliance. Currently vmware don't have a patch available so have to use command line workarounds.
So far the only saving grace is that the vsphere exsi host servers aren't affected by this.
Imagine working for a network services company when something like this happens. You have customers who run apache on their own servers. And what do they do? They contact you to ask if there's anything you can do on the network to protect them.
Then imagine this query being repeated for multiple customers all day.
Erm how about keeping shit patched up to date on your servers guys?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
