I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs with log4j or not, and your developers are probably aware of this when they configured logging. You shouldn't need to pour over code to figure it out.
It would be far worse if this exploit existed in slf4j or commons-logging.
The major risk here probably isn't in-house developed code but versions of log4j used in a vast array of packaged software and systems.
https://github.com/cisagov/log4j-affected-db <-- that's a (probably incomplete) list of possibly affected vendors and applications, and in many cases the vendor can't even say yet whether they're vulnerable.
Yup. Here's a concrete example -- my team owns a couple of java services. They're spring boot with slf4j as our logging wrapper, using the default logging implementation of logback -- we didn't opt for log4j. So we're good, right? Well, let's do a `gradle dependencies` and see if we're pulling it in transitively -- still good. See some `log4j-api`, but no `log4j-core`. We're not actually doing any logging with log4j -- the "api" is from spring to allow you to use log4j if you want. Again, we're not, so we're fine.
Oh, but it does turn out that we do have the elastic apm agent, and it has log4j as a shaded dependency. So not as free and clear as we thought, and damn hard to detect that.
Shaded dependencies are a nightmare, and it's a particular bone I have to pick with using Elastic products that they think this practice is ok.
I prefer to package all my projects into a single fat jar, since it makes distribution so easy and clean, but if I was creating jar files with the expectation that other projects would use them I would make sure to package everything separately.
In this case using fat jars made things really easy to check for the effected classes and luckily for me I also didn't have any log4j-core classes in my fat jars.
log4j-api isn't actually a problem (directly). It's the usage of log4j-core that has the JndiManager class that's the injection point for RCE.
In the case of the transient dependency, it's further complicated because we've seen that some packages repackage the JARs they depend on... that means that statically analyzing for log4j is very difficult because you can't use hashes (even if you unzip the jar and hash class files directly).
I've been working on a scanner for this stuff on GitHub[0], and it's a real pain in the neck lol. Especially for Vendor software that you don't control.
log4j is in widespread use, directly or indirectly.
Most people don't give a crap about the exact Java logging library, the only places that actually care are those that bike shed, since functionally Java logging stuff is generally quite robust and full featured.
The worst part about my previous phrase is that the places that don't care about the Java logging library frequently don't do security audits, so prepare for a ton of exploits and data leaks in the following months and years.
Using logging facades means that libraries don't need to update -- which is great -- but libraries were never directly vulnerable anyway. log4j is, to my knowledge, still by far the most common actual implementation of logging in the Java ecosystem. The assertion that it's not popular for logging only holds if you assume that logging facades are logging implementations, which they are not.
My completely-unverified guess would be that there are more people immune to this issue because they never migrated past log4j 1.x than there are who are immune because they picked up Logback or something similar.
> You shouldn't need to pour over code to figure it out.
This is true but as sibling comments have pointed out, a lot of other software you might be deploying without having written or configured the logging for are written in Java.
Most people using e.g. spring boot or quarkus would end up using the defaults that come with those frameworks. For spring boot, the default is actually logback. However, you can switch it to log4j2. https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-s...
Log4j2 never quite got the same status that v1 had. V1 should be considered a bit obsolete at this point. It still works of course but it has some performance issues that both log4j2 and logback try to address.
The issue with high profile vulnerabilities like this is that there are a lot of projects where dependencies are rarely updated.
I update aggressively on my own projects to stay on top of changes and keep the effort related to mitigating compatibility issues at a minimum. A nice side effect is that you get all the latest security, performance, and other fixes. In my experience, updates get harder the further you fall behind. So, the longer you wait, the more likely you will have a lot of fallout from updates and the more likely it is that you will be exposed to pretty serious bugs that have since been addressed upstream.
If you are like me, I can recommend the excellent refreshVersions plugin for gradle. It makes staying on top of dependency updates a breeze. I run it every few weeks to spend a few minutes updating misc libraries, and verifying everything still works. Run the command, update to the suggested versions, create a pull request and merge when it works.
Occasionally there are issues with specific libraries but 95% of the updates are completely painless and the remainder are usually pretty easy to deal with. And if there are show stopper issues, I want to know about them and document them why we can't update.
I would recommend doing the same for packaged software. I work with a lot of customers running ancient versions of whatever for no other reason than that they seem a combination of fearful, ignorant, and indifferent about what will break because they can't be bothered to even try. Mostly updating them to more recent versions isn't that big of a deal and it tends to address a multitude of performance, security, and other issues.
> For spring boot, the default is actually logback.
I did not know this, thanks for letting me know!
> I update aggressively on my own projects to stay on top of changes and keep the effort related to mitigating compatibility issues at a minimum. A nice side effect is that you get all the latest security, performance, and other fixes. In my experience, updates get harder the further you fall behind.
This is absolutely a best practice, though I think people struggle with it for all sorts of reasons. In general one of the downsides of maintaining a diverse codebase is that this constant update cycle becomes more and more difficult, and it's one of the things that I find drives towards more consistent tooling within a team.
> I work with a lot of customers running ancient versions of whatever for no other reason than that they seem a combination of fearful, ignorant, and indifferent about what will break because they can't be bothered to even try.
While I agree this is something people need to get over, we have to take some blame for this as an industry. A lot of people have bad experiences with upstream Shiny Object Syndrome.
That's my observation. My favourites are the projects where the last commit was 5 years ago with a copy-pasted log4j stanza that must have been 4 years old at that point, which now can't practically be upgraded at all because of the bitrot and loss of organisational knowledge. I've seen one that needed somewhat special measures just to regain access to the source code...
I can't say I'm feeling the same. Still lots of people testing over at https://log4shell.tools almost a week after this vulnerability became widely known. Plenty of people still discovering they're vulnerable as well. I think it's likely that these are just the people who know they're using log4j. If you're running a black box product from some vendor you'll have no clue you're vulnerable until it's too late.
I have ported a Spring Boot application from log4j to logback and it was pretty easy since we used slf4j. The code was the same, the only thing I had to do is to convert the logging configuration. The features mapped one to one and it to some fidgeting to make it work, but all in all it was pretty straight forward. Would recommend.
The fact that putting these strings in the name of an iPhone or a Tesla was vulnerable suggests to me that there are plenty of vulnerable systems out there.
My initial reaction was also tentative skepticism. Not that the package isn't popular, but that it must be hard to find real world interactions where you can successfully get a payload in, and a lot fewer still where you can actually execute it.
Yet we have seen a large number of high profile hacks already, and they keep coming. Turns out that not only are there many ancient java versions in use, the aren't very compartmentalized either.
Is there a list of successful hacks anywhere? Most of what i've seen on Twitter is someone posting an attack string to a website, then showing a record of a DNS lookup, which is some distance from actually being a successful exploit.
It would be far worse if this exploit existed in slf4j or commons-logging.