Some information I gathered. Providing as information. Information -official statement from the maintainer: https://logging.apache.org/log4j/2.x/ -official SAS statement: https://support.sas.com/content/support/en/security-bulletins/remote-code-execution-vulnerability-cve-2021-44228.html -there is log4j -> not affected (important to note that there is version 1 and version 2). -there is Log4j2 2.0-beta9 <= 2.14.1 which are vulnerable -Search for ‘log4j2’ jar files in your sas config and sas binary folder to identify threaths -I identified log4j2 versions that are affected in SAS components on SAS9.4M6 (gemfire, SAS Environment Manager) How do we mitigate? -Update log4j2 to version 2.15, it can be as simple as replacing the *.jar files. This is not an easy task, as SAS uses different components that use different versions of log4j2 -For those who cannot upgrade to 2.15.0, in releases >=2.10, this behaviour can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true . -For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m . -For versions >=2.0-beta9 and <=2.10.0 the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class For windows this can be as easy as opening the jarfile with 7zip and deleting the class. In my opinion, if you have the possibility, waiting for a SAS Hotfix as solution is optimal. It is not entirely clear what is the impact at this very moment. Making changes to your environment is always risky, know what you are doing (!) and have a rollback scenario. -Setting the environment should be a safe mitigation, this will not provide a solution to all affected versions however. -Replacing the jarfile with version 2.15 is not always possible due different java versions: Log4j 2.13.0 and greater require Java 8. Version 2.4 through 2.12.1 required Java 7 (the Log4j team no longer supports Java 7). Some features require optional dependencies; the documentation for these features will specify the required dependencies. -Removing the class from the jarfile should be safe, I have not tried and verified this. -When you perform these actions, a restart is required. -In my opinion, if you have the possibility, waiting for a SAS Hotfix as solution is optimal.
... View more