Table of Contents
- CVSS score of 10
- What it does and why it's so bad
- It‘s not sufficient to look for log4*.jar files in your systems
- The Discovery
- Attempt to fix the JNDI
- But wait, there's more!
- What does this mean for TSM and Rubrik
dffd
1. CVSS score of 10
We've seen a lot of very bad vulnerabilities over the years with CVSS scores of 9.8. But, of course, that's out of a maximum of 10. Many security IT people have wondered what a CVSS score of 10 might look like. Well, we don´t need to wonder no more.
CVE-2021-44228, which has been assigned to track the vulnerability known as “Log4Shell” have earned itself the maximum possible CVSS score of 10.0. They don't come any worse than this.
This is the only instance in which Bruce Schnierer's oft quoted pithy observation that “vulnerabilities only ever get worse, they never get better” does not apply... because THIS ONE cannot possibly get any worse. It's already the worst that it can get.
2. What it does and why it's so bad
“Log4j” is a very widely used — as in many many millions of installations — kind of everywhere, open-source server-logging JAVA framework. Its job is to log things that happen on a JAVA server. Like the contents of form submissions or HTTP query metadata details, and such. This JAVA-based open-source software has been found to contain an incredibly dangerous and readily exploitable feature which allows remotely located attackers to cause the execution of any code they design on a target’s system. And because this is deliberately universal cross-platform JAVA code, its opportunity for exploitation is also universal and cross-platform. The problem has to do with JNDI (Java Naming and Directory Interface).
3. The discovery
The flaw was originally discovered during a bug bounty engagement against Minecraft servers. Some frisky Minecraft users were using it to execute programs on the computers of other users, simply by pasting a short message into a chat box. Yes, it's truly that easy to exploit, which as much as anything explains its CVSS rating of 10.
4. It‘s not sufficient to look for log4*.jar files in your systems
When Google was asked why fixing the JVM ecosystem was so hard, their open-source team explained that by far most JAVA modules depend upon Log4j indirectly. And the deeper the vulnerability is down the dependency chain, the more steps are required for it to be fixed since the bottommost module, where the direct dependency exists, must be fixed first. Then the module that depends upon that module needs to be rebuilt using its dependency which is now fixed. And then the module above that one needs to be rebuilt, and so on.
This depth that log4j has been embedded into our systems is the 2nd reason why this is such a bad situation. Only 17% of our systems are directly using log4j, most common is 4 layer‘s down. And those log4j files can be "obfuscated“ or hidden within executables or binary files. So you can expect that you‘ll probably only find a small subset of your whole attack vector by doing a flat file search for this thing.
This is also why this is going to continue to be a major concern for a long time in the foreseeable future.
5. Attempt to fix the JNDI
Since the CVE became published there have been 3 versions published 2.15, 2.16, 2.17. The first attempt to fix the JNDI turned out to be unsuccessful thus the patch 2.15 is commonly considered to be flawed, but they did get it correctly the 2nd time, that eventually lead to the feature to be completely disabled in version 2.16.
So YES, if you have version 2.16 you HAVE FIXED the big one!
Deeper information
In version 2.15 they tried to fix the problem without disabling JNDI, (to be technical, they changed it so that only localhost could issue commands to it, as opposed to anyone anywhere before). But the attackers found way around that almost within 48 hours from the fix issued, so the next one 2,16 completely disabled it (as they should have done right from the get-go since it's almost never used this feature).
Version 2.15 they tried to fix the JNDI (but failed)
Version 2.16 it's disabled by default
6. But wait, there's more!
Not much later researchers discovered an entirely new Log4j attack vector which enables adversaries to exploit servers locally by using a JavaScript WebSocket connection. But that CVE "only" has a score of 7.5. This led to version 2.17. That's certainly not good, but it's not "house on fire CVE 10" that got fixed in version 2.16
Main takeaway here is this: It’s Urgent to upgrade to version 2.16 but if available upgrade to 2.17, don‘t wait for vendors to include the version 2.17 version as that only addresses the 7.5 CVE, the big one is in version 2.16 and version 2.15 should be considered useless.
7. What does this mean for TSM and Rubrik
Rubrik recommends upgrading CDM as soon as possible to one of the patched versions (6.0.2-p1, 5.3.3-p6, or 5.2.3-p9). The fix available includes fix version 2.16. Rubrik is not impacted by the WebSocket one thus there‘s no need to address that one.
With IBM you want to go for the 8.13.2 fix patch and avoid using 8.1.13.1, as that one has 2.15 fix that didn't disable the JNDI. The important ones to patch are the IBM SP OC, SPP and TDP for VE (both VMware and HyperV).
If you need help to upgrade, don´t hesitate to reach out to Cristie.
