Log4J Vulnerability and IBM i

Last Updated on 19 December 2021 by Roberto De Pedrini

Thousands of blog posts and social media have already been written on the vulnerability of the Apache Log4j Library (also known as Log4Shell). Even newspapers and television stations are talking about it.

Indeed it is a “bug” that could create quite a few problems, considering that this Open Source library is used in thousands or perhaps millions of applications, from servers to desktops up to the whole IOT world.

Not being a security expert, I limited myself to trying to understand how much this vulnerability can affect my and my client’s IBM i systems by following the advice of industry experts.

Let’s start immediately dotting the i’s and crossing the t’s … we are talking about Apache but let’s not confuse it with Apache Web Server, the latter is not subject to the Log4Shell problem! (see at https://www.seidengroup.com/2021/12/13/no-apache-isnt-vulnerable-to-the-log4j-vulnerability/?utm_source=hootsuite&utm_medium=AlanLI&utm_term=&utm_content=&utm_campaign=blog )

IBM Product Security Incident Response (Psirt)

We look for more info on the IBM IBM Product Security Incident Response PSIRT site which collects important information about the security of the various IBM solutions that in recent periods focuses mainly on this vulnerability: https://www.ibm.com/blogs/psirt/

At this link ( https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/#list-of-products ) we also find a list of products not subject to this problem.

As far as IBM i is concerned, we find solutions such as Websphere Application Server, HMC Hardware Management Console and who knows how many products from independent vendors.

OS security and PTFs

As a first piece of advice, beyond this specific Log4J problem, IBM and the systems experts of the platform have always advised us to stay up to date with the OS versions and the relative update PTFs … not only to have the latest features made available by the Rochester laboratories available but also to install the appropriate security patches.

Is your system up-to-date with the latest group-PTFs?

A quick check can be done with a simple SQL script (of course only available on the latest versions of operating system with 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;

In the screenshot above, relating to an updated 7.4 system in these days where we see that new PTFs of the groups relating to IBM HTTP Server, Security etc. are already available.

Which versions of Log4J are potentially at risk?

The versions of Log4J potentially at risk for this vulnerability are those from version 2.10 to version 2.15 … the old versions 1.x, used in many applications including IBM i, are not, on the other hand, vulnerable to this “exploit” (but, potentially, they are at risk for several other vulnerabilities of the past!)

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?

If we want to check our system to understand if and which versions of Log4J are present (then we should also understand if they are used!), We can download this excellent 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 of our IFS that contain the word “log4j” in the file name. In addition to this there may be Java libraries and objects with Log4j embedded in the packages, it is also advisable to do the searches listed below.

I try to run Scott Forstie’s script on some system and I find I see the string “log4j” appear in several files and directories. Going to look closer I find several log4j to version 1.x (quiet but not too much!) and some log4j to version 2.8 for Websphere Application Server …. which I am then going to update by following the instructions on this site: https://www.ibm.com/support/pages/node/6526686

As mentioned above … this 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 …. we can then resort to a search with “find” from the QSH environment or better still from an SSH session … from which several .ear / .war are highlighted with log4j … in my case always related to Websphere Application Server!

# 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 contains a 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”?

Of course by installing the latest PTFs or updating third-party software that uses this Java log4j library.

However, one thing that we can do immediately at no cost is to disable the offending features of log4j … an operation that unfortunately only affects the log4j versions from 2.10 to 2.15 …. previous versions 2.x ignore these settings instead … In short… a piece that only partially covers the hole … but better than nothing!

So let’s follow Jesse Gorzinski’s instructions and 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 in a certain way related to our “IBM i” and often used by developers and systems engineers we can mention:

Isphere TN5250: Probably all of us who use Rational Rdi have installed the great Isphere plugin … Isphere is not at risk, per se, by not making use of “log4j” … but the 5250 emulator that we can download in the Isphere downloads uses Log4j even if at a 1.2x version … Thomas Raddatz of Isphere has already made the updates of Isphere available to version 4.2.3.r …. we invite you to update Isphere on your Rational Rdi!

Ardgate – Jvagate: Excellent Open Source solution to integrate databases such as Oracle, MS SQL Server, etc into our IBM i applications. Java application that uses Log4j, but, again, to a previous version not particularly subject to log4shell risks.

J ava THEN: Even the Java POI, Java service libraries often used to read or generate Excel files from IBM i use Log4j, even if at versions 1.x …

X-Analysis: This excellent tool from Fresche also uses Log4j but Fresche has made an update patch readily available (promptly communicated to the owners of the product).

Conclusion

Having IBM i, known for its reliability and security, we generally feel quite safe from a virus point of view. This is not always the case, if system hardware and software, if kept appropriately updated, are certainly a great certainty, we cannot guarantee it for all our applications, or those of third parties, which now make more and more use of libraries available globally, as in the case of Log4j … which could therefore put millions of systems and equipment at risk (not only servers and PCs but also tablets, smartphones, printers up to the car or the heating system!

In short, keep your eyes peeled!