So, I’ve seen a load of headlines today warning of a security weakness that was apparently identified on Friday. A bit surprised there’s no thread about it? Or is discussion happening somewhere and I just didn’t pick up on it?
The new vulnerability affects the widely used library Log4j which was created by apache. The Log4j vulnerability allows remote code execution by simply typing a specific string into a textbox. It was first discovered by Minecraft players but soon after it was realized that this vulnerability wasn’t just a Minecraft exploit, It works on every program using the Log4j library.
This is one of the worst vulnerabilities we have had in the last 10 years and this is just a very simple surface-level article if you are running Log4j I would recommend temporarily shutting down your application and looking deeper into how to fix the vulnerability.
Thats quite a statement… The Qt3 hivemind is pretty tech-savy, is this really that bad or is the media exaggerating things here?
It’s pretty bad. As widespread as Heartbleed from a few years ago - the bug in openssl that basically everybody integrated into their codebases. But this one is a little more front end. Any (web) exposed java app that allows data entry and is using this logging backend module is potentially susceptible to remote code execution, meaning an easy attack vector.
The ease at which this will be exploited sets it apart from Heartbleed, though. It won’t require much in the way of specialist expertise, or reliance on already having penetrated a target. This could be a primary attack vector and mechanism with which to move sideways once command and control is established by an attacker.
log4j is EVERYWHERE in the java world. I mean - you can shut it down, but now your applications are running blind from an administrative perspective as log4j is how you figure out what is going on with your applications.
It’s terrible. Easy to exploit, arbitrary remote code execution that’s pretty straightforward, LOADS of possible targets, not all of them easily patchable. It’s a disaster.
The good news is that it only affects Java-based projects that use Log4J (which, granted, is the vast majority of them nowadays), so it isn’t as far-reaching as the OpenSSL vulnerabilities, but this one is much easier to exploit. So yeah, it’s bad. Could be worse, but it’s bad. And what worries me the most is all the IoT stuff that might be really easy (well, easier) to exploit right now.
Ya, the issue with this is that it’s extremely widespread… Java is the backbone of a huge number (still most?) of large scale enterprise systems, and this results in a significant vulnerability.
Talking to folks at my old company - looks like this is an issue with log4j2. The software package we supported fortunately still used log4j - the older version which is not effected by this (fortunate as the package we supported was/is a widely used application monitoring software, so its everywhere).
So legacy apps (pre 2014) or devs that didn’t feel like switching are safe.
No, it’s a trivial fix for everybody, you just change that one flag to mitigate it and then the exploit no longer works. Or upgrade, of course. But you do need to actually do that, if you forget about it for even a couple of weeks you’re probably gonna have a bad time.
This one is actually gaming-adjacent, it was discovered for a bug bounty on the java version of Minecraft. You chat with that LDAP string in a minecraft server and instapwn it.
That assumes you have control over the arguments in a repeatable way. If you are running 3rd party systems like ElasticSearch, REd hat OpenShift, Splunk (though I think I read splunk uses v1 so it’s ok), etc… then you are still vulnerable to having your whole infrastructure owned. Any user facing desktop application that fetches data from the web (I wonder if IntelliJ uses log4j2) can potentially cause the RCE to be invoked, and good luck getting users to know how to change their jvm vars.
If you are containerized you have to make sure that any system that restarts itself still restarts it with all the flags.
Not only that, If I understand it correctly the jvm flags only fix the RCE. AIUI there’s still the potential that your environment variables can be exfiltrated even after the JVM flags are set.
I run an ELK stack and it was a very simple upgrade. But sure, there can be complexity in your specific config making even the argument change a pain in the arse.
Wait, so (let’s say) MS can’t just patch Word, every user has to not just keep their software up to date but “patch” their own client or the whole system is vulnerable? Or are you just saying that the code could be invoked on a particular unpatched/unflagfixed client, ie the bad actor would need access to that specific client first through some other means?
If your company has a custom application that is written in Java that customer service uses, that applications write logs with log4j (so internal IT can debug issues), and that client ends up logging something that triggers this RCE (could be phishing attack) then that will end up injecting code to be run on that customer service’s user computer as that user. Their code now has unfettered access behind your company’s firewalls.
Libreoffice is a good example where this could be the case (though no idea if they use log4j).
A good example is people were RCE-ing other minecraft players because the Minecraft client was vulnerable to this. This allowed people to run custom code on the machines of other Minecraft players.
The client side issue is actually why I think this is worse than Heartbleed, because it doesn’t only impact server side software.
Fixed our Java services at work on Friday. On Saturday we saw from access logs that our services were being probed for the vulnerability. Bullet dodged.
It’s that bad if you’re using Java w/ that library. Doubly so if it’s on publicly facing services (edit: more accurate would be, if the inputs to the service are coming from untrusted sources, whether the service itself is publicly facing or not).
The difficulty of the fix isn’t really the thing. It’s the need to update many, many servers, making 100% sure you didn’t miss one, without disrupting the services they are supporting more than necessary. It’s a massive, massive disruption to operations, even for organizations that have a response plan in place for this sort of thing.
Then you have the long tail of, “Do we know whether anyone exploited this against us before we fixed it? How do we know that?” and all of that sort of incident post-mortem stuff. It’s a gift that’ll keep giving for a while.
