Background:
The log4j vulnerability described in CVE-2021-44228 was the result of log4j's JNDI functionality, which allowed developers to provide variables and functions to log4j that would be expanded/executed on the fly. The issue arises when user input is not sanitized, and users are able to pass in crafty strings that are executed by log4j. While this is a vulnerability in and of itself as sensitive information can be leaked, the reason that remote code execution can be accomplished is the fact that JNDI also has the ability to initialize serialized Java objects returned by JNDI functions. Therefore, a malicious user could provide a custom crafted string that would cause log4j to reach out to an e.g. LDAP server of their choosing which would then respond with a serialized Java object containing a constructor with arbitrary code, which would then be executed by log4j on the target machine.

After looking into our codebase, I found that while we do not directly depend on log4j, we have two dependencies that do. These are Commons Logging v1.2 and Logback Classic v1.1.2.

• It looks like the latest version of commons logging uses log4j 1.2.17, and since IGB uses an older version, it shouldn’t be vulnerable to the log4j issue.
• Slf4j (Section “Does a similar vulnerability exist in logback?”), states that logback is not vulnerable to the log4j issue.

I am curious about this statement from the previous comment:

"JNDI also has the ability to initialize serialized Java objects returned by JNDI functions."

What functions do this? Can you find a good, basic tutorial explaining what this is?

log4j2 uses a variety of lookup methods to substitute messages into logging statements. One of these is the JNDI lookup, which is based on the respective Java API. A part of the JNDI API is the LDAP service. The Serializable Objects section at the previous link describes how serialized objects are deserialized. To achieve remote code execution, however, the object being deserialized must be specifically crafted to exploit a deserialization vulnerability. An example of how hackers craft these objects is here. In addition to LDAP, the RMI and COBRA JNDI services can also be used to load remote objects and can, therefore, also be used for exploiting deserialization.

No basic tutorial explaining what JNDI actually is and what it's good for appears available. Moving to closed.