(Updated December 26, 2021)
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 )
Index
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/
(Updated December 26, 2021)
Among the products widely used in the IBM i environment we find DB2 Web Query for which updates are available at the following link: https://www.ibm.com/support/pages/node/6529238?myns=ibmivers&mync=E&cm_sp=ibmivers--NULL--E
Also ACS, Java application, naturally uses Log4J, even if still at version 1.2.17 (not 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 I invite you to download as soon as possible
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.
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.
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 )
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
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
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).
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!
I leave you some links to deepen the subject if you want to know more about this vulnerability:
https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j
https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
https://www.itechsol.com/ipower-hour-episode-36-log4j2-vulnerability-are-you-affected/
--- Roberto De Pedrini Faq400.comWe are pleased to receive and share this "tip & trick" from Patrick Rizzi, which introduces a technique that allows…
I take inspiration from a response by Michael Mayer on the Midrange.com mailing lists to someone who asked how to…
Businesses are increasingly seeking tools to enhance efficiency, collaboration, and resource management. Enterprise Resource Planning (ERP) systems provide a comprehensive…
Early April saw the release of the "Spring Version" of ACS Access Client Solution, version 1.1.9.5 Interesting new features especially…
If the packed agenda of sessions at Common Europe Congress 2024, June 3-6 Milan, wasn't enough for you, here's another…
Debugging functions with Visual Studio Code have been available for some time but this new version 2.10.0 simplifies the handling…
View Comments
Roberto -- thanks for your awesome script; I've made some modifications to it suitable for multi-partition investigations, below.
# Log4j_scan scripts
# EAR and WAR files need to be unpacked using jar -xf filename.war in a temp dir, examine
# ------------------------------------
path=/
outfile=/home/systems/scripts/log4j_scan_result_$HOSTNAME.txt
# -------------------------------------------------------------------------
# folder to scan
cd $path
# re-create outfile
rm -f $outfile
touch -C 1208 $outfile
echo " " >> $outfile
echo "log4j_files_using_jndi" >> $outfile
for i in `find . | grep log4j | grep '\.jar$'`; do echo $i; jar tf $i | grep -i jndi; done >> $outfile
echo " " >> $outfile
echo "dot_ear_files_containing_log4j" >> $outfile
for i in `find . | grep \.ear$`; do echo $i; jar tf $i | grep -i log4j; done >> $outfile
echo " " >> $outfile
echo "dot_war_files_containing_log4j" >> $outfile
for i in `find . | grep \.war$`; do echo $i; jar tf $i | grep -i log4j; done >> $outfile
Log4j vulnerabilities have pivoted from LDAP to JVM RMI leaving the IBM i vulnerable. In addition, log4j v1.x has logged (pun intended) 3 new CVEs since Jan. 2022 and these are critical vulnerabilities with no mitigation. Don't be fooled, log4j v 1.x is critically vulnerable and out of service since 2015 meaning that no fixes will be released. Detect and call vendors to update to version 2.17.1. BFB Security can be contacted for other vulnerabilities. I was the Senior Cybersecurity Architect for IBM Rochester Lab Services and keynote speaker at the LUG for many years and now head BFB Security, an IBM Business Partner specializing in IBM i remediation.