Dear IRIS Community Software and Web Service Developers-
There is a well-publicized remote code execution (RCE) vulnerability discovered in "log4j 2" referred to in the CVE bulletin ( CVE-2021-44228 https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228 ), given its highest serverity rating.
log4j is a popular Apache library that facilitates logging services for many of the Java code we have come to know and love. Log4j has had two major release versions, a 1.x version and a 2.x version. These two versions are not cross-compatible with each other.
The exploit described in the "Log4Shell" vulnerability described above can allow an external unauthorized actor to run arbitrary code on the running system, following the exploitation of a JNDI feature introduced in the 2.x version of log4j. The current guidance for all code and software packages running a 2.x version of log4j is to upgrade your version of log4j to the latest v2.15.0. Other users who still use an older 2.x version can protect themselves with configuration changes, as outlined in the CISA guidance page found here:
IRIS responded quickly to the CVE bulletin on December 10th and discovered minimal mitigation requirements in its software and systems. Those systems deemed vulnerable have since been patched and redeployed with the fix.
Related to web services is our Web Service Shell (WSS) product:
WSS is a sidecar utility to enable FDSN-compliant web services to be constructed and business logic attached. WSS depends on a logging library that has been confirmed to run the 1.x version of log4j (v1.2.16). Therefore, *the Web Service Shell is by all accounts safe from this RCE exploit.*
For additional security in your web service shell deployment, there is something you can do with your software as far as configuration, or your .jar library contents. This comes from our good friends at the Southern California Earthquake Data Center (SCEDC) at Caltech:
================ For Log4j 1.x ===============================
Version 1.x is NOT vulnerable unless the included JMSAppender is enabled in log4j's configuration file (i.e., in log4j.properties or log4j.xml). Its author states that you can safely remove JMSAppender from the log4j-1.2.17.jar artifact yourself using this command:
zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class
If you do not have access to 'zip', you can also use the 'jar' command.
#assume log4j-1.2.17.jar exists in current directory
jar xvf ../log4j-1.2.17.jar
jar cvf ../log4j-1.2.17-patched.jar .
Final note: log4j 1.x does remain vulnerable to an unrelated, older exploit, CVE-2019-17571.
Deputy Director, Cyberinfrastructure
IRIS Data Services