Dynatrace OpenShift Operator (latest) Critical Vulnerabilities

[yair_mashmor]

Hi all,

We are working on upgrading our OpenShift Dynatrace operator to version 0.9.1.

in this process, our security tools found these vulnerabilities in the docker image:

CVE-2022-23218 glibc - critical 9.8
CVE-2022-23219 glibc - critical 9.8
CVE-2021-38604 glibc - high 7.5
CVE-2021-3998 glibc - high 7.5
CVE-2021-43396 glibc - high 7.5

The number at the end is a reference to the severity score of the issue( taken form https://nvd.nist.gov/vuln/detail/CVE-2022-23218).

Did someone else came across this? did you find a workaround?

Dynatrace - is there a planned fix for this?

Thank you,

Yair

[MaciejNeumann]

Hi @yair_mashmor,

I've found the ticket about the same issue, and the response was that the dependencies will be updated in the next release, which should resolve this issue. The base image will be updated to the latest version with the release of the v0.10.0 operator.

[stefan_penner · Accepted solution]

Hi @yair_mashmor ,

many thanks for your request and the details you shared regarding the results of your vulnerability scan.

TL;DR
We use ubi-micro 9 as our base image (Operator 0.9 -> ubi micro 9; Operator 0.10 -> ubi micro 9.1) which is not affected by this vulnerability.

More Details
We are aware that, depending on which vulnerability scanner you use, there might be scan results reporting CVE-2022-23218 for the Dynatrace Operator Image. The root cause of this scan result is tied to the base image which is used by the Operator (RedHat Ubi-9 micro). As you can imagine, we are in frequent, close contact with RedHat and already exchanged information with them months ago.

RedHat confirmed that ubi-9 micro (which is based on rhel 9) is not affected by this vulnerability:
https://access.redhat.com/security/cve/cve-2022-23218

Operator version 0.9.x uses ubi-9 micro as base images, whereas the next operator version (0.10.x) will be based on ubi-9.1 micro. Both operator versions are not affected as stated above.

Hope that helps!

[yair_mashmor]

Thank you for your detailed answer @stefan_penner.

So, if ubi-micro 9 is not affected by these vulnerabilities, I wonder why do they come up in the scan?

Also, by using the same scan tool on the upcoming version, do you think these vulnerabilities will come up as well? if they will not, that would solve this issue, but if they will, we will have to give an explanation as to why these vulnerabilities come up in the scan, although they are not affected by it.

Thank you for you help,

Yair

[stefan_penner · Accepted solution]

Hi @yair_mashmor ,

unfortunately, many vulnerability scans result in false positive results.

The majority of vulnerability scanners primarily scans for packages / libraries which are used in software components and maps the library name/version with known vulnerabilities. However, they don't encounter whether relevant functionalities/code paths are used at all, already fixed or can even be exploited.

In this specific case, the base image "ubi9 micro" uses a glibc library. Red Hat backported a fix to the older version of the package and has not yet upgraded to a newer glibc version (note: we requested an upgrade).

Here's the statement of Red Hat (see FAQ on the CVE description)
"In order to maintain code stability and compatibility, Red Hat usually does not rebase packages to entirely new versions. Instead, we backport fixes and new features to an older version of the package we distribute. This can result in some security scanners that only consider the package version to report the package as vulnerable. To avoid this, we suggest that you use an OVAL-compatible security scanner like OpenSCAP."

Why do we even use ubi-micro?
In order to be able to release our operator on OperatorHub, RedHat requires to use this base image.

We understand that false-positives cause uncertainties and friction in your daily work. Hence, we are currently assessing how we can proactively share information about such topics with you in a meaningful way. We will keep you posted.

Hope this helps!

Best Regards,
Stefan

[yair_mashmor]

I really appreciate your answer @stefan_penner.

The info in the ticket and in your replay helped us tremendously.

Thank you!