References:
RiDP is taking this matter seriously, and is currently reviewing all our offerings to determine the impact and scope of this exploit. Updates to this emerging situation will be captured here.
For information about this and other potential security vulnerabilities related to Ricoh products and services vist our Alerts and Security Vulnerabilities Announcements.
RXOP
RXOP v3.8.7 has been released which mitigates the JNDI vulnerabilities described in CVE-2021-44228 (and others). Furthermore, the log4j jarfiles bundled with RXOP have been modified to disable JNDI lookups completely, which mitigates JNDI attack vectors.
Impacted releases: RXOP v3.8.6. RXOP 3.8.5 and earlier do not use log4j v2 and thus are not vulnerable to those exploits related to log4j version 2.
RXOP does not use the JNDI specific functionality that is at the heart of the exploit. We have determined that RXOP v3.8.6 cannot be used to leverage this exploit.
It is important to note that RXOP is a Java library. The log4j2 dependency libraries are shipped with RXOP as a convenience for consumers of the library. Applications that use RXOP can update the log4j2 jarfiles to the recommended versions in their application build and runtime environments and the application VM will use those libraries instead. RiDP can confirm that replacing the log4j-api-2.14.1.jar and log4j-core-2.14.1.jar libraries provided in RXOP 3.8.6 with the "-2.17.1" versions fetched directly from Apache or Maven (and changing any build, packaging, or runtime configuration that may use hard-coded versions names) works without error.
The assumption is that any future log4j 2.x version would be API compatible and would also work without error, but RXOP developers are encouraged to test their applications fully when making any dependency change.
There is also a documented mitigation involving setting a Java property on the VM running the RXOP application: passing -Dlog4j2.formatMsgNoLookups=true to the startup parameters of the VM running the application will mitigate the exploit.
SmartSDK
No impact. This library is not used in the SmartSDK.
SDK/J
Any logging framework referenced by the DSDK uses classes derived from Log4j v1, and thus is not vulnerable to this v2 exploit.
AAA
AAA v2.x
AAA v2.2.1 references the SLF4J logging façade only. Thus, the concrete logging framework chosen is up to the implementing AAA application.
Implementors are encouraged to review their AAA applications to see if they can be exploited, as RiDP cannot guarantee a AAA Provider or AAA Client made using the AAA abstract classes cannot be exploited since the choice of using an exploitable library is made by the implementor.
AAA v1.x
The logging framework used is based on Log4j v1, and thus is not vulnerable to this v2 exploit.