Blog
In our blog you will find many exciting articles about i‑effect®, EDI and IBM i. If you have suggestions for a topic that interests you, we look forward to your suggestions.
Note about i‑effect® and the Log4j vulnerability (CVE-2021-44228)
Abstract - The gap in the Log4j software component is currently being reported by many sides. i‑effect® is not affected by the security vulnerability CVE-2021-44228 in Log4j 2.x. In older versions of i‑effect®, however, version 1.2 of Log4j was used in the ZUGFeRD module. Even though this version is not affected by CVE-2021-44228, we recommend users of i‑effect® 2.7.62 (only the ZUGFeRD module) to update to the latest i‑effect® version due to another less critical vulnerability in Log4j 1.2 (CVE-2021-4104).
Thursday, 16. December 2021
Is i‑effect® affected by the Log4j vulnerability?
No, the standard software components of i‑effect® are not affected by the current Log4j vulnerability (CVE-2021-44228) after examining the source code and the changelog of the latest versions.
Log4j is no longer used in our software in current versions, i‑effect® uses a different logging framework (SLF4j + Logback) for logging.
Furthermore, also not affected by the security vulnerability:
- the "Apache Tomcat" server used in i‑effect® in conjunction with module *WEBCONTRL
- the files "log4j-over-slf4j.jar", "log4j-to-slf4j.jar" and "log4j-api.jar".
Log4j 1.x in older version of i‑effect® (i-effect 2.7.62 in connection *ZUGFERD)
In older versions of i‑effect® and in a few versions within version 2.7, version Log4j 1.2 was used for a short time by the ZUGFeRD module. The versions 1.x of LOG4j, however, are not affected by the current vulnerability CVE-2021-44228, because these do not include lookups.
For version 1.2, there is another vulnerability (CVE-2021-4104) where an attacker could perform a similar attack in combination with a setting by changing the Log4 configuration. According to the BSI, exploitation is only possible in combination with a malicious program configuration and is therefore rather unlikely.
“The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.”
In perspective, users with i‑effect® version 2.7.62 and the *ZUGFERD module to update the ZUGFeRD obsolete version of LOG4j 1.2 should upgrade to a current i‑effect® version.
What you should check anyway!
Affected could be active users of the *SOA module or other individual developments. Please come in this case for the purpose of further review in any case to us.
Even if your i‑effect® version is >= 2.8, there might still be directories and files of previous versions like 2.6, 2.7 etc. in the IFS. If there is the affected Log4j file/version "log4j-core-*.jar" in it, it has no effect, because these files are not used by the newer i‑effect® versions. You can delete these JAR files without any problems.
Sources:
https://www.kb.cert.org/vuls/id/930724
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549177-1032.pdf?__blob=publicationFile&v=3
http://slf4j.org/log4shell.html
https://cert.uni-stuttgart.de/log4j/