December 2021 Security Alert

By now, we hope you have heard about the Log4j2 vulnerability called Log4Shell, and that it can potentially affect your IBM i if you are using certain versions of Log4j2 in any of your applications.

Log4Shell Vulnerability – Need to check if Log4j2 is being used

As with any security vulnerability, one of the best things to do is keep up to date with PTFs. You should be regularly applying IBM PTFs to your system so that known security fixes are installed. If you don’t have the experience to put PTFs on, or you just don’t wish to do it for any reason, we can put PTFs on to your system, either one time, or better on a regular cadence. Contact Ron Dolan at for more information.

Over the past week, IBM has been steadily publishing information on what products are and are not affected. The products that have been announced with mitigation recommendations. The products that have been announced as not affected are located here:

Please note the following products in the not affected list as of 7:30 AM on December 16th, 2021 include:

  • IBM i Access Family
  • IBM PowerHA System Mirror for i
  • IBM i Portfolio of products under the Group SWMA
  • OmniFind Text Search Server for DB2 for i
  • Rational Developer for i
  • IBM Application Runtime Expert for i
  • IBM Backup, Recovery, and Media Services for i
  • IBM Db2 Mirror for i

Areas of concern remain any IBM products that may run on or affiliated with IBM i such as WebSphere Application Server versions 8.5 and 9.0, Hardware Management Console, independent software vendor products or custom software.

To clear up a misconception, the issue is with Log4J 2.0 through 2.15 and not version 1. Versions of Log4J between versions 2.0 and 2.15 only are to be deemed a concern.

There are a few different ways to determine what versions of Log4J are installed on your system:

  1. Scott Forstie has posted a handy script using IBM i Services located here. Please note that this works for IBM i 7.3 and higher.
  2. For 7.2 or lower, you can use the following shell script. The script posted the other day did not account for case sensitivity whereas this does:

cd /
find . -type d \( -path ./QDLS -o -path ./QFileSvr.400 -o -path ./QIMGCLG -o
-path ./QNTC -o -path ./QOPT -o -path ./QSYS.LIB -o -path ./QSYS.LIB \) -prune -o -name ‘*[lL][oO][gG]4[jJ]*’ -print

If any versions of Log4J are found between versions 2.0 and 2.15, please update to 2.16 if it’s custom software or report the issue to your software vendor. Version 2.15 will mitigate the Log4Shell vulnerability, however that version has a Denial of Service vulnerability. Moving to 2.16 is the advised version at this point.

On IBM i, for Log4J versions 2.10 and higher, you can mitigate the Log4Shell vulnerability by adding an environment variable (i.e., ‘ADDENVVAR ENVVAR(LOG4J_FORMAT_MSG_NO_LOOKUPS) VALUE(‘true’) REPLACE(*YES) LEVEL(*SYS)’). However, we would recommend getting to version 2.16.

Another misconception is that people think this is an Apache HTTP Server issue. It’s not. Log4J is a Java-based utility supported by the Apache Foundation.

Review current security bulletins from the IBM Product Security Incident Response (PSIRT) site.

At this time the CVE-2021-4428 is not listed as an IBM i Apache vulnerability.

NIST link below shows how to resolve at this time.
CVE-2021-44228 is still being investigated by the NIST. is tracking as well.

There are some great details and an explanation about how it is used to exploit data here

Remember, security isn’t a one-and-done process, it’s an ongoing process that must be constantly updated as new vulnerabilities arise. Speaking of which, have you ever had an IBM i security assessment done? You would be surprised at how many security issues we find when we do a security assessment or penetration test. My customers think they are secure, then we show up and show them things that are wrong. Don’t let your security be compromised, the job you save may be your own. Contact Ron Dolan at iTech Solutions to get started.

5 thoughts on “December 2021 Security Alert”

  1. It is important to clarify that ‘Apache’ in the vulnerability refers to the Apache Software Foundation which maintains thousands of pieces of source. We in the IBM i community often use the term “Apache” in referring specifically to the web server that runs on our system. While that is also a piece of Apache software, the vulnerability is NOT related to the Apache Server, but rather to the Log4j component that Apache also maintains.
    – Larry

  2. Pete,

    Did not find anything under find /qibm/proddata -name log4j-core-2*.jar.
    So for curiosity sake, I did find /qibm/proddata -name log4j*.jar
    I found /qibm/proddata/OS/WebServices/internal/engines/org.apache.axis2-15/WEB-INF/lib/log4j-1.2.15.jar
    Tried the same thing for find /qibm/userdata -name log4j*.jar

    Do I need to be concerned?

  3. The original focus on CVE-2021-44228 has led to some confusion. In looking beyond CVE-2021-44228, the current list of CVEs affecting log4j versions 1 and 2 are listed below:

    Log4j 1.x

    Log4j 2.x

    Everyone is urged to mitigate by removing all versions of log4j 1.x and 2.x prior to version 2.17.1. Scan for all versions prior to version 2.17 including 1.x using the tools listed.

Leave a Comment

Your email address will not be published. Required fields are marked *