FOLLOWING

According to Elastic search website there is some mitigation available for elastic search

discuss.elastic.co/.../291476

Yes, i have added -Dlog4j2.formatMsgNoLookups=true in the  JVM_OPTIONS file for Elastic Search and restart the services. But we have alot of different version of X3 and elastic search out there, For the old bundled elastic search i have used the managermode of the service and added the parameters.

how exactly did you do this? i need to also do the same thing. Did you figuire out how to fix it in the SAP business objects? our SOC found that was installed by sage x3 "C:\program files (x86)\sap businessobjects\sap businessobjects enterprise xi 4.0\java\lib\external\axis2\1.6.2\log4j-1.2.15.jar"

Is the sap  business objects you mention a part of the printserver installation or is it development tools for crystal reports?

im not sure. i think its the crystal reports thats on the erp web server. 

it appears to be deeply integrated into crystal reports generation. 

it seems that log4j version 1 is not impacted

Latest news from  Sage X3 support: 

The log4j security issue revealed at the end of last week has been taken into account by our services. Our R&D teams are working now to offer you a security fix.
We will get back to you as soon as we have more information.

Sage X3 support will probably published the security fix on this link :

support.na.sage.com/.../viewdocument.do true

Is Sage X3 version 9 affected Log4j vulnerabilities?

Although the mitigation listed on the Elastic website is to use the parameter switches, the information on the Apache website (https://logging.apache.org/log4j/2.x/security.html) has an update to state that this does NOT work.

Until the 7.16.1 version is verified by Sage the best course of action is to disable Elasticsearch. 

A workaround that we have put in place for customers for whom Elasticsearch is a necessity is to remove the JndpiLookup class from the log4j-core jar package as per the Apache site.  As they put it "in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class".
We did this quite simply by shutting down the service, opening the log4j-core jar package (in all our instances this was log4j-core-2.11.1.jar) with 7zip File Manager, navigating to the class (org/apache/logging/log4j/core/lookup/JndiLookup.class) and deleting it. Save the changes and start Elasticsearch again.

With regards to version affected it is only log4j version 2 that is affected - the log4j packages with SQL and Crystal Reports are as far as I've detected all version 1 files, which are not affected by THIS security issue and should be safe.  It is also only the core packages that are affected (the ones with the Jnpi Lookup class) - api packages are not affected.

One more point that should be mentioned is that some reverse proxies - which are often put in place to protect X3 instances published externally - have also been shown to be using log4j 2 packages, so get your connectivity provider to check those too.

X3 instances that are not published externally can also be susceptible to internal attack vectors through SPAM and other means of infiltration, so care should also be taken to protect from "internal" attacks.  There are reports (not X3 related as far as I know) of networks being compromised simply by people opening emails that contain payloads.