Scan your Cloud Integration tenant for Log4j libraries with CPILint

[MortenWittrock]

A few days ago, a serious vulnerability in the Apache Log4j library was made public. Log4j is a very widely used open source logging library. If this vulnerability is successfully exploited, an attacker can execute their own code on the system hosting the library. In other words: it’s bad. The vulnerability is present in all Log4j releases from 2.0 beta 9 and onwards. Fortunately, there is a fix: Upgrading to Log4j version 2.15.0 or later, where the exploitable behaviour is disabled by default. You can read more about the vulnerability, designated CVE-2021-44228, here.

If you are a Cloud Integration customer, you have probably received an email from SAP by now, urging you to check your iflows for use of the Log4j library and to upgrade to a safe version as soon as possible. What to do is described in Note 3130846 (the note also states that Cloud Integration itself is not vulnerable to the exploit). If you have a very large number of iflows, this is a cumbersome task and one that is prone to human error. If you are running CPILint, however, you can accomplish it easily.

CPILint is my automated governance tool for Cloud Integration. It lets you check your iflows against a number of rules covering best practices, connectivity, security and more. You can read a longer introduction to CPILint here. And no, CPILint does not use Log4j 😉

The tool ships with a rule called JavaArchives that lets you allow or disallow certain Java libraries. If we use this rule to disallow Log4j, CPILInt will scan the tenant and output a list of iflows that contain Log4j JAR files and are therefore not compliant. This list can then be used to make sure that only version 2.15.0 is in use.

The JavaArchives rule allows or disallows libraries based on JAR file names and it supports wildcards. Based on the Apache Log4j vulnerability page, it seems to me (but please verify this on your own!) that the relevant JAR files are called log4j-core-*.jar. We can disallow those with the following rule:

<?xml version="1.0" encoding="UTF-8"?>

<cpilint>

    <rules>

        <disallowed-java-archives>

            <disallow>log4j-core-*.jar</disallow>

        </disallowed-java-archives>

    </rules>

</cpilint>

To perform the scan, save the rules file to a file called, say, disallow-log4j.xml. Then run CPILint as follows:

cpilint -rules disallow-log4j.xml -tmn-host <your TMN hostname> -username <your username>

(The Tenant Management Node hostname is the hostname you see in the browser, when you use the Web UI.)

I added the safe version of Log4j to a sample iflow and this is the output I received from CPILint:

Before using this technique, please note the following caveats:

• Using the described technique in response to CVE-2021-44228 is at your own risk.


• CPILint only checks iflow artifacts, so JAR files uploaded to Script Collection and Message Mapping artifacts are not checked. You need to go through these artifacts manually.


• Log4j JAR files that have been renamed will not be detected.


• CPILint only checks iflow resources, so custom adapters using Log4j will not be detected.


• Log4j class files that have been distributed inside other JAR files will not be detected.


• You should do your own verification of the JAR file naming scheme utilised by the rule.


• CPILint is distributed under the MIT license, which means that the tool comes with no warranty whatsoever.