A note on the global “log4j” security vulnerability
rswanson
Wed, 12/15/2021 – 17:30
This week brought news of an exploitable hack to which certain applications executing Java may be vulnerable. Specifically, any applications using the popular Apache log4j logging tool may, under certain circumstances, be exposed to hackers executing nefarious code on their servers. This includes applications running on IBM i.
While Valence does include a version of log4j for logging JDBC connection info when accessing remote databases through Nitro App Builder or the vvOut_execSQLtoJSON RPG Toolkit procedure, the log4j version Valence uses, 1.2.17, predates the exploitable functionality introduced in log4j version 2.0. Additionally, in Valence Java is used only as a backend-callable utility, which for remoteDB support runs inside a standalone non-CGI batch job called VBCH**** or VRMT****, and is not directly callable in any way from the UI. So there should be nothing to be concerned with insofar as Valence goes.
That said, out of an abundance of caution, the latest Valence 6 build (6.0.20211209.1) includes an update to the remoteDB logic that drops the use of the log4j utility entirely, using an alternative method to log JDBC activity into a log file. So once you download and install this build onto your system, you will have eliminated Valence’s use of any log4j routines altogether.
However you may still have other third party applications or custom programs using Java on your system that need to be addressed. As a quick stopgap measure, you can apply a system-level environment variable to disable JNDI lookups in more recent versions of log4j:
ADDENVVAR ENVVAR(LOG4J_FORMAT_MSG_NO_LOOKUPS) VALUE(‘true’) REPLACE(*YES) LEVEL(*SYS)
Even with this environment variable in place, it would be advisable to reach out to any third party application providers that may be using log4j on your system to see if they have a patch, which may include updating to log4j version 2.15.
For further information, IBM’s open source guru Jesse Gorzinski has published an article at Tech Channel with an IBM i-centric overview of the log4j problem, which includes a link to a piece by database guru Scott Forstie showing how to use SQL to locate any reference to “log4j” in your IFS. The folks at iTech Solutions Group have also provided simple instructions for manually scanning the IFS to find potentially vulnerable versions of log4j.
