Logged a Critical case with MF support. Surprised there's been no announcement so far. Have I missed it somewhere?

Checking CVE-2021-44228, setting log4j2.formatMsgNoLookups to true is enough:

From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to "true" or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Since we have an appliance (v4.5.0.3), which actually runs docker container for sspr.

To set java parameter for it, create file /ssprConfig/java.vmoptions with following:

-Dlog4j2.formatMsgNoLookups=true

After restarting appliance (or docker service) you can see this running ps aux | grep java:

root     17550  8.5 17.3 3196792 532684 ?      Sl   12:09   1:07 java -server -Xmx1g -Xms1g -Xlog:gc:file=/config/logs/gc.log:time,uptime,level,tags:filecount=10,filesize=10M -Dlog4j2.formatMsgNoLookups=true -jar /app/libs/sspr-onejar-4.5.0.3.jar -applicationPath /config

Please note that this fixes SSPR main web service, not jetty (port 9443), but I assume jetty is not exposed to internet.

Also we have not yet thoroughly tested SSPR, so I cannot tell you if there are any drawbacks on setting this parameter.

Some additional info I was kindly reminded by Alex McHugh.

It looks like SSPR is using log4j v1 (looking into docker image I can find only log4j-1.2.17.jar).

Also there are some reports that log4j v1 is not vulnerable, other says that it is (https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 )

But based on CVE, log4j2.formatMsgNoLookups works only for versions >2.10.

As a conclusion, I think that my previous solution is not useful. Either log4j2.formatMsgNoLookups parameter is not needed (log4j v1 is not vulnerable), or even if this version of log4v is vulnerable, parameter will probably not work (needs version >2.10.

Thanks - that's where my understanding is as well. I have v1 log4j and v0 syslog4j in the Linux installed  version of SSPR so I think that has probably saved us. Radio silence from MF on my "critical" support ticket logged 40+ hours ago.

SSPR is based on open source PWM and we got a semi-official answer from one of the main developers for PWM regarding this yesterday.

https://groups.google.com/g/pwm-general/c/mjf4fEzz0b0

So safe to assume that SSPR is safe.

SSPR uses Log4j version 1.x, which is not affected by the vulnerability.  

the announcement by MF can be found here: https://community.microfocus.com/cyberres/b/sws-22/posts/summary-of-cyberres-impact-from-log4j-or-logshell-logjam-cve-2021-44228