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.
-
Just for safety, [I've asked the NLog developers whether NLog might suffer from similar vularabilities, too](https://github.com/NLog/NLog/issues/4710). Hopefully they will answer my question. – Uwe Keim Dec 13 '21 at 13:52
-
7There is now [an unofficial XCKD](https://i.imgur.com/o52Ap4W.png) for CVE-2021-44228 (based on [this one](https://xkcd.com/327/)). – Uwe Keim Dec 13 '21 at 19:47
3 Answers
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.
![](../../users/profiles/242928.webp)
- 7,828
- 16
- 15
-
12are you able to cite any references to help support your answer? This is an important question, and it would be great to have some references to help. Thanks! – Gary Ewan Park Dec 11 '21 at 21:48
-
43The [CVE entry](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) clearly states that it uses JNDI. Since Perl, PHP, .NET, and R don't use the JVM, they can't possibly support the requisite interface. The CVE entry also states no other vulnerable software. – bk2204 Dec 12 '21 at 01:23
-
4@GaryEwanPark The exploit is that arbitrary Java byte code can be run using JNDI on the JVM. If you don't have a JVM there is nothin to run on. – Thorbjørn Ravn Andersen Dec 14 '21 at 15:08
Let me start with some background info. As I understand it, the CVE-2021-44228 ("Log4Shell") vulnerability has three main components:
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 setlog4j2.formatMsgNoLookups
to true in version 2.10.0+) address.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.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.
![](../../users/profiles/5457.webp)
- 4,386
- 18
- 28
-
14I can confirm that log4net version 2.0.13 outputs the string verbatim and does not perform any substitutions. – John Dec 13 '21 at 15:23
-
6When I've read about that vulnaribility, I couldn't understand a bit how it was expected to work, until I've run a code sample. It was beyond my understanding how someone could build in such an un-feature in an open source project on the reputable platform (Apache). A design flaw is the most diplomatic term to describe it. – Danubian Sailor Dec 14 '21 at 07:49
-
3
-
1Also note that anything that *parses* the logs might be vulnerable. Twitter thread: https://twitter.com/ebrandwine/status/1470876450744147978 – Shadur Dec 15 '21 at 20:18
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.
![](../../users/profiles/271387.webp)
- 59
- 2
-
2Why are you only considering the .net environment, the question was about more. Also I don’t know if the .net doesn’t implement the jdni interface. Cause that’s where the bug “comes from”… – LvB Dec 13 '21 at 11:41
-
4Well @LvB one cool thing about Q&A sites is that you can provide an answer that only focuses on one part of the question without having to also explain how every compiler since the beginning of computing was constructed. Focusing on a framework/language that Prasad is familiar with is of benefit to people also using that particular framework/language, while people not using that framework/language can ignore it, or learn more that may tangentially relate to them. As Ruby also does not implement Java, this _applies_ to Ruby as well. – jcolebrand Dec 13 '21 at 19:48
-
Firstly, if you do that you should clarify you are only awnsering the question partly. Secondly you totally disregard the actual vulnerability… regarding the JDNI lookup… (I don’t think it’s vulnerable but that’s just my suspicions I didn’t check it.) – LvB Dec 13 '21 at 19:50
-
However @LvB, Prasad is not going to presume to be an expert on all things, they just want to talk about the one thing, and that's perfectly ok on a Q&A site. Other answers can elaborate on other things. It sounds like you could use more understanding of where the bug "comes from" yourself, and it is ok if you use comments to elaborate that you would like more education on that part. – jcolebrand Dec 13 '21 at 19:50
-
@jcolebrand this is the Security Stack exchange. We had. A bit tighter guidelines for awnsers than the rest of SE for obvious reasons…. And all I am saying is that the awnser should be clear about what it does and what it doesn’t awnser – LvB Dec 13 '21 at 19:53
-
3Then perhaps @LvB it is better to link to the meta- conversation here to help the clearly (21 rep) new user understand the norms of the site, and be helpful to introduce them to how this particular SE site operates, and what the shared norms are. Inclusivity is something we should all practice daily, nobody is perfect at it. Part of inclusivity is introduction to social norms in a constructive way. Your comment clearly comes across to me as hositle, altho I can now see your attempt to merely provide pro-social-contract form. I understand better now, because you explained to me. – jcolebrand Dec 13 '21 at 20:01
-
1@jcolebrand I am sorry you felt my interaction it was hostile, it wasn’t meant to be. (It’s also why I didn’t link to the meta article… since that feels like trying to best someone with the rules) I’ll try next time to be make my intentions more clear what I mean. And I don’t think inclusivity is at all at play… still what is at play is trying to get the right type of responses. And create a community that feels safe. So thank you for your comments. It helps to improve me, us all and the site. – LvB Dec 13 '21 at 20:06
-
@LvB I get your point. I was analyzing the effects of this vulnerability in .Net applications and stumbled upon this question. Once I got the complete picture, I thought it would be useful to help other people know the conclusion. I was so saturated that I didn't look at the question asked and replied anyways for .Net folks. jcolebrand thanks for sticking by the answer. As you rightly said comments help us improve and the site. Folks, SORRY for posting only for .Net applications and Thanks for supporting the answer. – Prasad Bhalerao Dec 14 '21 at 12:19
-
@PrasadBhalerao don’t think your awnser has no merit. It does it’s just limited In scope. (Which isn’t a problem in itself but should be explicitly there imho. ) – LvB Dec 14 '21 at 12:21
-
This presumes that none of the ports are poor/incomplete. To support the same featureset on a budget, one could take a shortcut by calling out to a small Java app for JNDI lookups (for example) rather than reimplementing that in the target language. Plus there are more indirect issues, like a .NET server passing data to a Java server. It's always good to be thorough when it comes to investigation of critical threats -- the number of servers that have Java installed despite not using it (or using it unwittingly) is quite high in my experience. – Matthew Read Dec 14 '21 at 19:21