Is xenforo vulnerable to log4j?
- Thread starter James T
- Start date
bzcomputers
Well-known member
It'll affect those using Redis also. Which I think is quite a few XenForo owners.
As best as we can establish currently Redis doesn't actually use Log4j by itself. I have seen mention of Redis being affected in some of the websites reporting on this but it's not clear why. It might be because of the Redis Java client Jedis, but I presume that's not relevant to most XF users.
ElasticSearch is impacted, and I know if you send malformed queries they can get logged so there is probably a pile of logging happening which is vulnerable.
While XenForo shouldn't be exploitable in standard configuration, applying migrations is still a very good idea.
While XenForo shouldn't be exploitable in standard configuration, applying migrations is still a very good idea.
That will certainly be our recommendation.
However, I'm not certain applications are as affected as feared.
Java JDK 8 update 121 implemented JNDI protections by default.
My understanding is this should mitigate the issues entirely as long as those values have been kept at their default of
With JDK 8u121 being released in January 2017 there is hope that a good chunk of servers are already running a build newer than that.
Our recommendations will be three-fold:
However, I'm not certain applications are as affected as feared.
Java JDK 8 update 121 implemented JNDI protections by default.
Code:
com.sun.jndi.rmi.object.trustURLCodebase
com.sun.jndi.cosnaming.object.trustURLCodebaseMy understanding is this should mitigate the issues entirely as long as those values have been kept at their default of
false. Elasticsearch 7.0 and up has bundled OpenJDK so they should be fine as-is.With JDK 8u121 being released in January 2017 there is hope that a good chunk of servers are already running a build newer than that.
Our recommendations will be three-fold:
- Implement
jvm.optionsfix - Update Java to JDK 8u121 or higher
- Update to Elasticsearch 6.4 or above (note the
jvm.optionsfix won't work in older versions because they use an older version of Log4j)
Official advice:
xenforo.com
PSA: Potential security vulnerability in Elasticsearch 5+ via Apache Log4j (Log4Shell)
It has come to our attention today that a vulnerability has been discovered in popular Java logging library Log4j 2 which may allow attackers to arbitrarily execute code (remote code execution). Apache Log4j 2 is bundled with and used in many Java applications including Elasticsearch. XenForo...
xenforo.com
It is really a nasty vulnerability.
A huge part of the issue is log4j will apply variable substitution rules on arguments, so any data passed to the logging system is a threat vector.
The following is affected;
Just as if you did this;
A huge part of the issue is log4j will apply variable substitution rules on arguments, so any data passed to the logging system is a threat vector.
The following is affected;
Java:
logger.log("{} foo", "bad string");
Java:
logger.log("bad string" + " foo");
thedude
Well-known member
CloudFlare's log4j mitigation write up says
In addition to Elasticsearch versions 6.4 and above, it appears many versions below 6.4 include log4j 2.11.1, which would quality for the formatMsgNoLookups mitigation method. Check for the existence of /usr/share/elasticsearch/lib/log4j-core-2.11.1.jar on your server running Elasticsearch. The XenForo PSA gives clear instructions on where and how to add the correct formatMsgNoLookups line, but the PSA should be updated to not exclude Elasticsearch 6.3 and below from the versions that can use the mitigation.
In addition to Elasticsearch versions 6.4 and above, it appears many versions below 6.4 include log4j 2.11.1, which would quality for the formatMsgNoLookups mitigation method. Check for the existence of /usr/share/elasticsearch/lib/log4j-core-2.11.1.jar on your server running Elasticsearch. The XenForo PSA gives clear instructions on where and how to add the correct formatMsgNoLookups line, but the PSA should be updated to not exclude Elasticsearch 6.3 and below from the versions that can use the mitigation.
Elasticsearch 6.3 includes Log4j 2.9.1.
You can see that here:
www.elastic.co
2.11.1 isn't included until 6.4.0:
www.elastic.co
You can see that here:
Elasticsearch 6.3.0
www.elastic.co
2.11.1 isn't included until 6.4.0:
Elasticsearch 6.4.0
www.elastic.co
thedude
Well-known member
Just to complicate things for you guys, https://www.elastic.co/downloads/past-releases/elasticsearch-5-6-16 which one of our servers is running includes 2.11.1. Not sure at which version the 5 series started including 2.11.1Elasticsearch 6.3 includes Log4j 2.9.1.
You can see that here:
Elasticsearch 6.3.0
2.11.1 isn't included until 6.4.0:
Elasticsearch 6.4.0
Apparently Elasticsearch itself may not actually be vulnerable to RCE since they use the Java Security Manager:
discuss.elastic.co
Though there is still the potential for information leaks.
Only Elasticsearch 6.8 and 7.16 will see official fixes for this.
Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31
Subject: Apache Log4j2 Vulnerability - CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 - ESA-2021-31 Note - We will update this announcement with new details as they emerge from our analysis. Please check back periodically. Update Log Dec 16, 2021 - 04:20 UTC - Update Summary...
discuss.elastic.co
Though there is still the potential for information leaks.
Only Elasticsearch 6.8 and 7.16 will see official fixes for this.
Similar threads
- Solved
- Question