It is in the news, it’s on news headlines and even time magazine has an article on this issue. This classic and very useful java library hitting mainstream feels so odd? Well, do you know what is log4j Vulnerability? I’m talking about the same.
Anyway in this article I will explain to you what exactly this log4j vulnerability is and why it happened? but also share something a little more important.
You see these vulnerabilities come and go right, this will likely get patched, people will move on, life will likely go on but this has actually got me thinking a little bit about open source in general and I’m beginning to look at open source libraries a little bit differently so let me explain.
Contents
What is Log4j?
You probably already know what log4j is? it’s a very popular java logging library that you can use for logging stuff from your code so you can log things to a file like when something goes wrong and it shows error messages then debug messages and then you can look up log files later and troubleshoot right, typical stuff.
Although to be honest logging libraries in java have always been a little bit of a mess. so even though it’s a bit of a mess overall log4j which is one of these logging library options has been doing its job pretty well for many many years now but there was a dark secret that was hidden under the surface.
What is Log4j Vulnerability?
Log4j Vulnerability is a vulnerability found in the Log4j Open Source Library managed by a famous software company “Apache”. A hacker can exploit this critical vulnerability to gain Remote access to any system.
A major security vulnerability that’s now come into the open and we have a big issue on our hands. Any java application that uses log4j can be hacked that is anything lower than the recently patched version of log4j which is 2.16 right? This vulnerability cause enterprises racing to patch their log4j versions and deploy the newest version
and it also results in hackers racing to exploit targets before it’s set into prices do a patch.
This is interesting and now you might look at your app and go well hey I don’t I’ve no problem because I don’t use log4j, well, log4j is a very popular library that even if you aren’t using it directly you might be depending on another library which actually uses log4j for logging or that might depend on another library which uses lot4j.
At this point when you know how popular log4j is there is a high probability that any decently sized java application working out there probably has log4j installed on it.
There’s a security company for developers called Snyk, it found that about more than 60 percent of java applications that they scanned actually use log4j indirectly.
So this is a widespread vulnerability and now not only is this problem widespread but the severity level is pretty high too.
CVSS
There is a parameter called the CVSS score which stands for Common Vulnerability Scoring System and this parameter (CVSS) score has actually rated 10 for this vulnerability it’s 10 out of 10. The highest ever possible.
RCE
It stands for Remote Code Execution. What this means is?
In reality, it allows hackers to be able to run any code on your system by taking control of your application which uses a log4j. They can run any code of their choice.
I’ll be explaining the actual vulnerability in a little bit but I hope you understand why this is so serious. This is a reason this vulnerability is actually nicknamed log4shell.
Log4Shell
It’s exactly like anyone can open a shell on any server and run commands. It’s that verse. So this is big but what exactly is the problem itself? There are actually multiple things that have happened and all together resulted in this vulnerability.
Features of Log4j that cause this Vulnerability
Log4j Log Expressions
Log4j allows you to log expressions. This should be obvious because you can take log Expression by using a line of code.
JNDI
Now I’m going to introduce the second item in this article that just caused this problem which is a JNDI.
JNDI is a short form of Java Naming and Directory Interface. JNDI allows you to store java objects in a remote location and then serialize them kind of like streaming them to your JVM as scary as this might seem. This is a technology that’s been around for a while this was pre-rest API and this was a redistributed java system that would work with each other. This is how they would communicate. This has fallen out of popularity now but it is still there in java.
Similar to SQL Injection and Log Injection
All right this is what’s referred to as Remote Code Execution, does this remind you of anything?
Which has a similar vulnerability it’s called SQL injection we’ve seen something similar pattern.
This is very similar to what you can call log injection and log injection has been happening for a while. You can technically do log injection if you are not good at writing codes and it’s not even related to this vulnerability.
This is a really old technique and people handle it differently they don’t directly add the stuff they handle slash ends and all that but in the general log, injection is relatively harmless there’s not a lot of damage you can do.
What is the Solution of Log4J Vulnerability?
It’s an easy task to find out about log injection but Remote Code Execution is a much bigger problem. All right now how do you mitigate this?
JVM Flag
The first thing you can do or the easiest way to solve this problem is to set a couple of flags to false. There are two flags here which end with a trust URL code base.
Upgrade to a newer version of Log4j
You need to upgrade to the latest version of log4j and it should be a simple solution but it can also create problems if you have dependencies that depend on something else which depends on log4j.
Patch Class Directly
To resolve the dependency issue some companies have started to patch the class directly. They get the newest version of the class for the log release and they put it directly in the classpath so they know wherever there is this occurrence on this class
just patch this directly.
If you’re depending on some luxury and that uses log4j, well
do you wait for that library to fix the issue first before you publish your version? Well, that can take a while or they may not even do it. So a simpler solution is to just patch it directly.
Use Dependency Constraints
If you’re still using Gradle, you should know dependency constraints in Gradle. You are strictly recommended to use the latest version of the library to resolve this problem before a potential threat can leverage it to hack into your application.
Conclusion (What is Log4J Vulnerability)
Now if you know what the Log4j Vulnerability issue is, the basic reason behind the scene is the open source has traditionally been thought to be secure by default because the code is open-sourced for everyone to see.
People use this reason often it’s like the code is out in the open so if there is a security vulnerability people will catch it and they will fix it.
This is usually been an argument for open source. This approach needs to be changed.
And also the companies who use Open Source systems should contribute to maintaining the security of these systems.
