Critical RCE Zero-Day Exploit Found in Popular Java Logging Library log4j, Affects Much Of The Internet – CloudSavvy IT

There is no greater hope in human life than survival. At the same time, it is important to live well. With that in mind, every content on the website is written so that a person can get all the information from here to start his life to make beautifully.

According to that, Technology is one of the topics. It is also a part of life. Read carefully Details of Technology related article

Critical RCE Zero-Day Exploit Found in Popular Java Logging Library log4j, Affects Much Of The Internet – CloudSavvy IT

A critical remote code execution vulnerability has been found in log4j, a very popular logging tool used by most of the industry. It’s extremely severe, affecting nearly every server running Java, and is very simple to exploit, so you will want to update and mitigate the issue ASAP.

How Does This Work?

The bug, tracked by CVE-2021-44228, likely affects almost any Java application using log4j, which is quite a few considering how ubiquitous it is. If your application ever logs a string sent in by a user, it’s probably vulnerable. As far as exploits go, it’s one of the worst ones this year, as it can target basically any server running Java in some fashion (though the primary attack vector may be harder on modern JDK versions, more on that below).

Essentially, the exploit allows an attacker to send your server any string like the following, and if it logs it somewhere in your app, your server will execute code hosted at that address.


This works because, when parsing this uniquely formatted string, log4j will make a request through the Java Naming and Directory Interface, which ends up sending a download request to an arbitrary endpoint. It downloads and deserializes the .class file in an insecure manner. Because Java classes can have static initializers that run whenever the class is compiled and referenced, this results in remote arbitrary code execution from a simple, short string. For example, a client could set their user-agent to this string, or otherwise include it in a request, and when your server logs it, it will trigger the exploit.

That’s pretty horrible, scoring a 9.8 on the CVSS scale. It falls just shy of the worst score, as despite how awful it is, it doesn’t affect any resources outside the scope of the targeted system (but does give application-level access to the server running the logger).

RELATED: How Are Security Vulnerabilities Ranked? (CVSS)

It’s going to affect a lot of applications. For example, Minecraft was one of the first to spread the news and patch the exploit, as it was possible to execute code both on servers and on all players connected to a server through the in-game chat messages. An hotfix update for the game was released to patch the bug.

Popular services like Steam and iCloud have already been found to be vulnerable, and security research firm GreyNoise has already detected multiple IPs running scans for vulnerable servers.

You’re probably already running log4j, as it’s included in hundreds of other libaries as the standard logging tool. However, JDK versions greater than 6u2117u2018u191, and 11.0.1 are not affected by the primary attack vector  (using LDAP) that’s being exploited right now. That isn’t to say you shouldn’t update, since the bug in log4j + JNDI is still severe, and can easily be used with other attack vectors as well.

How Do I Fix It?

Luckily, there is already a fix that patches it entirely, so you should update your servers ASAP. This affects client applications as well though, which also need to update for this critical patch. After all, 3 billion devices run Java, so it’s going to be a while before it’s fully fixed.

The exploit has already been patched in log4j‘s latest release, 2.15.0-rc2, so you should update that if you can. The patch has also been backported to earlier versions, given the severity for users who may be stuck on legacy releases.

If you’re using another library that uses log4j, you should still be able to manually update in most cases, but if you can’t, you can use this JVM flag to mitigate the issue, which simply tells log4j to never do any lookups when formatting messages.


Did you like this article?
Share it on any of the following social media channels below to give us your vote. Your feedback helps us improve.

Other related Technologies ideas you might enjoy

Related Articles

Leave a Reply

Your email address will not be published.