Re: NVD - CVE-2021-4104 (nist.gov)
For information about this and other potential security vulnerabilities related to Ricoh products and services vist our Alerts and Security Vulnerabilities Announcements.
RXOP
This vulnerablility has been identified in log4j version 1.x,
Potentially related versions: RXOP v3.8.5 or earlier only. RXOP v3.8.6 (or later) is not vulnerable to this exploit because it depends on log4j version 2.x.
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. RiDP recommend updating your RXOP application to use RXOP v3.8.7.
RXOP is a library that does not set any non-default log4j configuration, including the JMSAppendor property that is the vector of attack in this exploit.
Therefore, applications using RXOP v3.8.5 or earlier are not vulnerable to this exploit as long as they do not set (or allow to be set) the JMSAppender property in their own log4j configurations.
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
AAA does not set the non-default JMSAppender property in the log4j configuration, and thus is not vulnerable to this exploit as long as an attacker does not have the abiliity to change the configuration.
Implementors of AAA applications are encouraged to secure and review their applications to ensure their applications guard against this.
SmartSDK
No impact. This library is not used in the SmartSDK.
SDK/J
SDK/J does not offer a readily available concrete logger, so the choice of logger is made by authors of SDK/J xlets or servlets. The internal logger referenced in some cases may be based on log4j v1 which has had the JNDI functionality removed and is not configurable.
Thus, an SDK/J xlet or servlet cannot access this concrete logger; even if an xlet or servlet could access this concreete logger, the logger itself cannot be configured to accept JMSAppender or coerced to issue JNDI requests.