Over the last few months, there have been many blog posts and technical breakdowns written on the vulnerability of the Log4j exploit. There are even memes about it, as it has permeated popular culture with the exploit affecting the highly popular game Minecraft.
The Log4J vulnerability is one that had the potential to create mass disruption as this CVE (Common Vulnerabilities and Exposures) affects a component in a common Open Source library that is used in thousands or perhaps millions of applications, from servers to desktops and even IoT devices.
Having a SecOps background, I wanted to understand how much this vulnerability can affect IBM Power systems by following the advice of industry experts.
The Apache Log4j vulnerability is tracked under CVE-2021-45105 and CVE-2021-45046. IBM states that work will continue to mitigate or remediate these vulnerabilities in products and services that are affected. Skytap’s infrastructure and known customer workloads have been patched and remediated to protect against this vulnerability – our IBM experts took quick action to solve this issue.
With so much active industry research on Log4j, mitigation and remediation recommendations will continue to evolve, so in the meantime, here are some recommended actions for other organizations running Apache Log4j:
- Check for vulnerable versions of Apache Log4j in your environments and applications
- Implement the latest patch to production environments as soon as possible
- Monitor IBM PSIRT for security bulletins
- Monitor for vendor patches as they become available
- Implement network controls such as egress controls or Web Application Firewalls to limit the exploitation of new vulnerabilities
You can also review the list of products not subject to this problem at this IBM page: https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/#list-of-products
For those systems that are affected, per the Apache Log4j security vulnerability advisory, the following temporary mitigation may provide interim protection for clients who are unable to upgrade Log4j in their workloads quickly: in releases 2.x to 2.15, this behavior can be mitigated by removing the JndiLookup class from the classpath:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
DB2 Web Query impacts and remediations
Among the products widely used in the IBM i environment, we find DB2 Web Query for which updates are available here: https://www.ibm.com/support/pages/node/6529238?myns=ibmivers&mync=E&cm_sp=ibmivers–NULL–E
ACS Access Client Solution
ACS, a Java application, naturally uses Log4J, even if still at version 1.2.17 (not known to be subject to the problem). IBM has however released version 1.1.8 of ACS updating the version of Log4J https://www.ibm.com/support/pages/ibm-i-access-client-solutions, which you should download as soon as possible.
As far as IBM i is concerned, we find solutions such as Websphere Application Server, HMC Hardware Management Console and who knows how many other products from independent vendors.
OS security and PTFs
IBM and systems experts of the platform have always advised us to stay up to date with the OS versions and the relative update PTFs. This ensures that you not only have the latest features made available by the Rochester laboratories available but also install the appropriate security patches.
A quick check can be done with a simple SQL script to validate that your machine has the latest PTFs and has the greatest chance of being protected.
Note: this script will only work on IBM i machines running the latest versions of the operating system and have direct Internet access.
— Check Group PTF Status
select PTF_GROUP_ID “Group ID”,
PTF_GROUP_TITLE “Description”,
PTF_GROUP_CURRENCY “Update state”,
PTF_GROUP_STATUS_ON_SYSTEM “Status”,
PTF_GROUP_LEVEL_INSTALLED “Installed Level”,
PTF_GROUP_LEVEL_AVAILABLE “Available Level”,
PTF_GROUP_LAST_UPDATED_BY_IBM “Last Updated By IBM”
from SYSTOOLS.GROUP_PTF_CURRENCY
order by PTF_GROUP_CURRENCY desc,
PTF_GROUP_ID;
The versions of Log4J potentially at risk for this vulnerability are those from version 2.10 to version 2.15.
The older versions 1.x, used in many applications including IBM i, are not vulnerable to this specific exploit but, potentially, they are at risk for several other vulnerabilities of the past, so this is a good time to ensure that you start that migration process, and get your workloads upgraded and patched if you are able.
The latest version of Log4j 2.16 (for Java 8) was recently updated by the Apache Foundation just to solve the problem discussed here: https://logging.apache.org/log4j/2.x/index.html
What versions of Log4J are installed (and used) in our IBM i system?
To check your system to understand if and which versions of Log4J are present within your environment, you can download the following SQL script made available by Scott Forstie in his GitHub Gist: https://gist.github.com/forstie/9662d4c302f5224c66b7a4c409141a2c.
The script allows you to search for all objects in the Integrated File System (IFS) that contain the word “log4j” in the file name. In addition, there may be Java libraries and objects with Log4j embedded in the packages, so it is also advisable to do the searches listed below.
The search only highlights files with “log4j” in the name. If the log4j library is embedded in some Java EAR or WAR package it would not be found. In this instance, you can then search with “find” from the QSH environment or better yet from an SSH session from which several .ear / .war are highlighted with log4j Including Websphere Application Server entries.
# Start looking for log4j files using jndi
cd /
for i in `find . | grep log4j | grep ‘\.jar$’`; do echo $i; jar tf $i | grep -i jndi; done
# Now look for .ear files that contains a log4j … if you see “log4j”
# appear, unpack that .ear using jar -xf filename.ear in a temp dir and
# examine the log4j* jar
for i in `find . | grep \.ear$`; do echo $i; jar tf $i | grep -i log4j; done
# Now look for .war files that contain log4j … if you see “log4j”
# appear, unpack that .ear using jar -xf filename.war in a temp dir and
# examine the log4j* jar
for i in `find . | grep \.war$`; do echo $i; jar tf $i | grep -i log4j; done
How to protect yourself from the “log4shell”?
By installing the latest PTFs or updating third-party software that uses this Java log4j library, you stand the greatest chance of being secure against this CVE. However, one thing that we can do immediately at no cost is to disable the offending features of log4j. This operation unfortunately only affects the log4j versions from 2.10 to 2.15. Previous versions ignore these settings.
Using the following script linked below (provided by Jesse Gorzinski) will allow you to set the environment variable and the Java system default properties: https://github.com/ThePrez/IBMiOSS-utils/blob/master/avoid_log4shell.sh
Other IBM i correct products
Regarding other products that are related to IBM i and often used by developers and systems engineers:
Isphere TN5250: Those that use Rational RDI have likely installed the Isphere plugin. Isphere is not at risk directly as it is not making use of Log4J, however, the 5250 emulator that is downloadable in the Isphere uses Log4j even if at a 1.2x version. Isphere has made the update available to version 4.2.3.r, and it’s recommended to update Isphere on your Rational RDI.
Ardgate – Jvagate: An Open-Source solution to integrate databases such as Oracle, MS SQL Server, etc. into your IBM i applications. It is a Java application that uses Log4j, although running a previous version is not particularly subject to log4shell risks.
Conclusion
IBM i is known for its reliability and security. It is generally quite safe from a virus point of view. That said, it is very important that the hardware and software be kept appropriately updated.
For updated information on how the IBM Product Security Incident Response Team (PSIRT) is handling CVEs, you can visit their blog site which collects important information about the security of the various IBM solutions and in recent periods focuses mainly on this vulnerability: https://www.ibm.com/blogs/psirt/
Finally, here are some links to better strengthen your IBM i security posture around this vulnerability:
Set up Cloud Pak to support connectors: https://cloud.ibm.com/docs/cloud-pak-security
Connect IBM Power to Azure Sentinel: https://www.ibm.com/docs/en/cloud-paks/1.0?topic=connectors-configuring-microsoft-azure-sentinel-data-source-connection
Hunting for Log4J vulnerabilities with Azure Sentinel: https://www.eshlomo.us/hunting-log4j-with-sentinel/
