Does CVE-2021-44228 impact Log4j ports?

Question

Log4j has been ported to other languages, such as log4perl, log4php, log4net, and log4r. Are these ports vulnerable to CVE-2021-44228 as well? I believe that they aren't because the vulnerability uses JNDI (Java Naming and Directory Interface), which I doubt would be relevant in other languages.

Answer 1

That CVE does not impact the ports, only Log4j, since it requires the use of Java interfaces (and some JVM versions prevent the vulnerability from being exploited). It may be that the ports have similar vulnerabilities, but they would likely be of a substantially different nature such that we would issue a different CVE for them to help distinguish the vulnerabilities, patching, and remediation steps.

Answer 2

Let me start with some background info. As I understand it, the CVE-2021-44228 ("Log4Shell") vulnerability has three main components:

1. A design flaw in Log4j that makes it (by default, before version 2.15.0) parse and expand certain substrings delimited by ${ and }, known as lookups, not only in hardcoded formatting patterns but actually in all logged data, including any user inputs provided as parameters. This is the part that the recommended mitigation techniques (upgrade to 2.15.0+ or set log4j2.formatMsgNoLookups to true in version 2.10.0+) address.

2. A particular lookup named jndi, enabled by default, that allows using the JNDI (Java Naming and Directory Interface™) API to load data from arbitrary remote sources using protocols such as LDAP. Some of the alternative mitigation techniques for older pre-2.10.0 Log4j versions, like this Java agent hotfix, work by disabling this lookup.

3. Bugs and/or design flaws in the Java LDAP implementation that make it vulnerable to remote code execution if given suitable input data. There are known ways to mitigate these, but apparently the attack surface is broad and hard to eliminate completely.

The possibility of using JNDI + LDAP for remote code execution has actually been known for some time; the last link above is to a presentation from 2016 discussing it. Issues with the inappropriate application of lookups to all logged data in Log4j have also been known at least since 2017, when the option to turn it off was added in version 2.10.0. But apparently it wasn't considered a major security problem at the time (although IMO it should've been), since without the jndi lookup's ability to make external requests all(!) it allows is a limited form of log forgery.

It was really the combination of all three of these flaws that allowed elevating this easy-to-use but limited log forgery exploit (part 1) into an easy-to-use remote code execution exploit (parts 2 and 3).

(Also, once the RCE exploit became widely known, people figured out that parts 1 and 2 could also be used to leak sensitive data, like private keys stored in environment variables, in the remote requests without actually needing the RCE exploit from part 3. But AFAIK this was only discovered, or at least publicized, in the past few days after the RCE was already known.)

---

Anyway, the upshot of all this is that log4j ports to other languages may have the same design flaw (part 1 above) allowing lookups to be parsed in user input. However, JNDI (part 2) is specific to Java, so the full RCE exploit in its current form is unlikely to work on log4j ports to non-Java systems.

Of course, I would still consider parsing any string substitutions in untrusted log data to be a security flaw and at least a potential entry point for exploit. Given a potentially vulnerable system, you should be able to test its vulnerability to log4j-style lookup exploits by entering a string like:

TEST ${upper:foo} ${env:HOME:~} ${date:MM-dd-yyyy} ${base64:SGVsbG8gV29ybGQhCg==} $${foo}

somewhere where it will get logged. If all that gets logged is the verbatim input string with no changes, your system is probably not vulnerable. If any of the ${} blocks are replaced with something else in the logs, however, or if the $$ gets turned into $ or any other changes appear, you should report this to the maintainers of the port ASAP and, until it is fixed, look for ways to change this behavior locally e.g. via configuration.

Answer 3

As per the CVE site where common vulnerabilities are posted, it says it affects Log4J through JNDI configurations.

JNDI is – The Java Naming and Directory Interface™ (JNDI) is an application programming interface (API) that provides naming and directory functionality to applications written using the Java™ programming language.

Since in .Net applications we do not use Java or it's runtime, this vulnerability won't be affecting .Net world.