Apache Log4j java security issue? (affecting apple, google, amazon, steam..etc)

Also keep in mind, the vulnerable package isn’t log4j, but log4j2 (Apache’s continuation of it). Afaik, log4j hasn’t seen active development since 2015 and lacks the feature which contains this vulnerability.

(Just had to work all this out my own self today for a DICOM transport layer.)

To be honest, I only have a vague understanding what this means in practical terms? Am I using it somewhere? Kall mentioned I should avoid “java based games” in steam. What are those? From my basic understanding I associate Java with website plugins, though that doesn’t quite gel with all this server discussion…

What can / should I do as a layman to protect myself? Get a scriptblocker for my browser?

Thanks and sorry to out myself as such a pleb!

I don’t think you really need to worry about anything.

Even a Java based game (of which they are few… Minecraft is the biggest one I know of) there still essentially no danger for you.

What the exploit means, is that an attacker can execute command on a system, by passing text through the logger… This isn’t something which is really going to happen when you are running software on your machine. It’s perhaps POSSIBLE, but not likely.

The real issue, is that Java still forms the backbone of most large scale enterprise systems, and a lot of those systems tend to have logging, for various diagnostic purposes… And most logging is done with this library, because it works well.

What makes this attack so effective, is that it’s really common to log user input, so that means it’s generally really easy for an attacker to exploit this, because they can just enter data into the places that the system is designed to accept user inputs.

To take Minecraft as an example, you can use this to attack the server, simply by entering the commands into the chat system built into the game… Because the server can log those messages.

But even as another use in that server, I suspect that the attack wouldn’t affect YOU, because your client is likely not actually logging that stuff, so it’s not leveraging that library for that stuff. (I may be wrong here, I’ve not dug into the details of it’s application in Minecraft, this is just my speculation) so while the server is vulnerable, you as a simple player probably aren’t. Now, if you run your own Minecraft server? THEN you may have a problem.

But for all the stuff that Java is more commonly used? Back end server infrastructure? I doubt that’s going to have any kind of real impact for you as a simple end user.

What’s more likely, is that an attacker will exploit the vulnerability, and then use that to do other shady stuff like steal your information if the guys running those server systems weren’t doing their other stuff right.

But I don’t think you need to worry about your own system somehow being attacked, simply by virtue of you connecting to some Java based system.

Yeah, I’d generally agree with that. The heavy hitter stuff has updated (Minecraft, e.g.). If you want to be really, really paranoid, you could go do a bunch of research about stuff and avoid certain things until they update, but for an end user system, that’s pretty hardcore for this vulnerability. I wouldn’t worry about it unless you’re running a private (un-updated) minecraft server or something like that. So. Don’t panic.

Log4j 1 has its own RCEs that aren’t being addressed, so not sure how much a good thing that is.

Yep you are wrong there. Log4j was also used for client side logging and thus people were actively injecting code I to other people’s clients. I even saw a proof of concept of someone injecting a java port of Doom in the vanilla Minecraft client with this.

So any multiplayer Java game should probably warrant some waryness.

And not to stroke fears but there are active exploit attempts on this that contain ransomware payloads.

Well, that’s why I added that caveat, I wouldn’t have thought that the client would have been logging that.

It’s important to realize that (afaik) the client doesn’t actually have to show the logs (or write the logs somewhere) to be vulnerable. Just passing a properly formatted string that ends up into a logging call is enough.

Normally, these type of systems have all types of logging levels, but only critical ones are left on in released software. Developers themselves will have super detailed logging so when a bug happens they can quickly trace it down, but that level of logging is overkill for a released build. They don’t get rid of the logging statements on release though, they just configure the logger to do nothing if a logging attempt is made at a Debug or Trace level.

So if the client logs something at Debug level, but that level is disabled, the logging function just returns without doing anything. However, it’s not clear to me if writing logs to a disabled level would prevent this from being exploited, and thus even non-obvious code paths could be vulnerable.

I work for a company that provides ICT support and we, and several of our major customers’ ict departments, went into full ‘all hands to battlestations’ mode last saturday because of this.

The only reason this isn’t cataclysmic level bad is because it’s relatively easy to fix and because a number of apps still use the 2015 EoL version, which isn’t affected. Being lazy with updates pays off for once, I suppose.

That said, a lot of people are treating it as worse than Hearthbleed so maybe it is cataclysmic if everything in your environment runs on Java.

Well, there is the whole “hasn’t seen development since 2015”. So yeah ¯\_(ツ)_/¯

https://nvd.nist.gov/vuln/detail/CVE-2021-45046

image

Fun times. And the workaround for the first version doesn’t mitigate this.

If im reading it right, this is just DoS, not RCE, so a little better.

Are those fixing this issue by changing maven dependency versions considering transitive dependencies?

After a clean build on a fresh m2, check to see which versions of log4j exist in your repo. You may be surprised at the number of versions of log4j dragged into your project via trans dependencies. Not to mention the 100s (1000s?) of other dependencies dragged in.

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies

I was talking about updating to the 2.x version.

I believe that maven will use the version of a library that is specified closest to the root of your POM, so if you specify the version in your POM directly, it will override any other versions that are requested by transitive dependencies.

(looking at the maven docs you linked this is explained in the dependency mediation portion)

We’ve definitely seen this to be the case in things I’m looking at right now. Retail is notorious for running outdated software so yay us!

I feel for you having had to engage Microsoft for super duper extended special support for WinXP.

Ha! We’re not that bad (anymore…!)!

Now, do it again!

Oy

Easy fix just became hard fix.