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 firstname.lastname@example.org 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: https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/#list-of-products
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:
- 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. https://gist.github.com/forstie/9662d4c302f5224c66b7a4c409141a2c
- 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:
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.
Apache.org is tracking as well.
There are some great details and an explanation about how it is used to exploit data here https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j
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.