If you pay attention to tech news, you know what’s going on with log4j right now. It’s being called Log4Shell which is a great name. I’ll spare you repeating the details of the issue, there are many many stories about it at this point.
What I’ve not seen is a good explanation about why knowing if you are using log4j is hard, and fixing it will be even harder than finding it.
Hunting for log4j
If you have a java project, the very first thing you probably did was check to see if you are pulling in log4j as a dependency. The weird thing about Java projects is even if you aren’t using log4j, it could be in you project.
We’ve all heard about how dependencies also have dependencies. Pulling in one dependency could end up actually pulling in 3, because the package you want depends on two different packages. For example, if I want to use Package A
I also end up with Packages B and C installed. You can imagine one of these could be log4j. Now if I look at the source of my project, I only see I depend on Package A, no log4j here! But that doesn’t tell me anything about all the things that will end up in my project after it gets built and Package A pulls in its dependencies. This means you have to build your project before you can be absolutely certain what’s in it.
But wait, there’s more! In the Java world, there’s another layer of difficulty, embedded dependencies.
If we look at the above picture, it looks like we end up with 3 packages installed in our project, so if we go looking in to the built version, we expect to find 3 dependencies. In the Java world, it’s possible that Package A doesn’t just depend on B and C, it also embeds them inside of itself.
If we look at our built project, we will only see Package A. Packages B and C are there, but only if we can look inside Package A. Humans can’t really go digging around inside of all these packages, we really need tools to do this sort of digging. If you have hundreds of Java dependencies there’s no way you can look inside all of them (and some of those layers could have layers).
This is the challenge with finding log4j. There are going to be a lot of false negative reports where a product claims it doesn’t use log4j, but it does, only the log4j is hidden somewhere deep in the dependency mines. It would be wise for everyone to get their work checked on this one. You should also double check any vendor statements. This is going to be the ultimate case of trust but verify.
I wrote another article that discusses how to find log4j in the wild you can read here.
Fixing log4j is even harder
Now that we understand why finding log4j is going to be hard, we have to understand that fixing it is going to be even harder.
Let’s assume my project is used by other Java projects. My project contains Log4j, but only because I include a package named “dep” as a dependency. I of course want to update my version of log4j as soon as possible. Everyone using my project wants me to update my version of log4j.
The challenge is I have to wait for “dep” to update itself. Then I can update my project, then my users can update their projects. This is really hard to understand so I’m going to try to use some images to help. Imagine this layout
This is not an unreasonable dependency tree. You can see our project is “me” version 1.4.3, and we have users of our project, and we have our own dependencies. There exists a new log4j version, 2.15.0 that fixes the problem. This means the dep project has to pull in the new log4j and release a new update.
I can’t update my project with a new log4j until I have a new version of “dep”, so I wait for “dep” version 7.6.16 then I release version 1.4.4
And now that I have a new version (after waiting for the log4j and dep updates) my users can update their software.
This is why there will be products that don’t see updates for weeks or months. If log4j is somewhere deep in their dependency mines, they could be waiting for a lot of updates to happen.
It’s been a pretty wild couple of days. If you’ve been working on this all weekend long you deserve the gratitude of everyone, this is a rough issue and the folks doing the work truly deserve enormous credit. Hug or maybe fistbump everyone on your team that has to deal with log4j. We will be measuring this one in weeks and months, not days.
Open Source Security 