High security vulnerabilities CVE-2019-25013 & CVE-2021-33574 about minideb

[kobemtl]

Current build from debian 10. And there are HIGH: 17, CRITICAL: 4 vulnerabilities. Even debian 11 the latest there are 2 critical. Should we continue using debian? Damn, I can't use any image with critical and high vulnerability in my prod env.

[Mauraza]

Hi @kobemtl,

It is normal that there are vulnerabilities, that's why we keep the containers updated.

[james-w]

Hi, the Debian security team has determined that those issues are minor and won't be issuing updates for buster, so
they will remain as vulnerabilities in buster unless they change their minds.

[Mauraza]

Thanks for using the Bitnami container images! Bitnami releases a new revision for all the container images periodically, see https://hub.docker.com/r/bitnami/minideb/tags/?page=1&ordering=last_updated. The main reason to follow this approach is to ensure all the bundled system packages are updated to the latest available version.

This method doesn't guarantee there are no vulnerabilities in all of them since there are some packages with known vulnerabilities that are not fixed in the Debian OS. In those cases, we can't do anything apart from wait until a new version patching the issue appears in the system package manager of the distro.

You can find more info about Bitnami processes regarding CVEs and Vulnerability scanners at https://docs.bitnami.com/kubernetes/open-cve-policy/

[avineer]

We are using bitnami/minideb:buster image and we get the following high severity security issues.

CVE-2021-20309 - https://nvd.nist.gov/vuln/detail/CVE-2021-20309
CVE-2021-20312 - https://nvd.nist.gov/vuln/detail/CVE-2021-20312

We have a requirement to eliminate critical and high, security vulnerabilities.
How long would it take to address these security vulnerabilities in bitnami/minideb:buster ?

[Mauraza]

Hi @avineer,

Did you see my previous comment?

Thanks for using the Bitnami container images! Bitnami releases a new revision for all the container images periodically, see https://hub.docker.com/r/bitnami/minideb/tags/?page=1&ordering=last_updated. The main reason to follow this approach is to ensure all the bundled system packages are updated to the latest available version.

This method doesn't guarantee there are no vulnerabilities in all of them since there are some packages with known vulnerabilities that are not fixed in the Debian OS. In those cases, we can't do anything apart from wait until a new version patching the issue appears in the system package manager of the distro.

You can find more info about Bitnami processes regarding CVEs and Vulnerability scanners at https://docs.bitnami.com/kubernetes/open-cve-policy/

[marrws]

We are using bitnami/minideb:buster image and we get the following high severity security issues (9/1/2021).

https://security-tracker.debian.org/tracker/CVE-2019-25013 https://security-tracker.debian.org/tracker/CVE-2021-33574

We have a requirement to eliminate critical and high, security vulnerabilities. How long would it take to address these security vulnerabilities in bitnami/minideb:buster ?

From the README.md:

(...) In order to keep compatibility with Debian, we will not patch any vulnerabilities in Minideb directly. If Debian does not fix the CVE then it will also remain in Minideb. If you find a vulnerability that is fixed in Debian but not in the latest images of Minideb then please file an issue as that is not intentional. (...)

The CVE you mention is patched for bullseye¹ but not on buster, maybe consider an ungrade to minideb:bullseye instead.

Footnotes

1. https://security-tracker.debian.org/tracker/CVE-2019-25013 ↩

[mirekphd]

@kobemtl minideb is notoriously insecure in my opinion, it's high time to switch to competing images based on ubi8, Alpine, or even ubuntu...

For example even the rather permissive Clair scanner reveals several High vulnerabilities:

Listing most important vulnerabilities in bitnami-minideb:buster-clair-cve-scan-20220529-122109.txt:

Unapproved vulnerabilities:
| �[1;31mUnapproved�[0m | High CVE-2021-33574         | glibc        | 2.28-10+deb10u1        | The mq_notify function in the GNU C Library (aka glibc)      |
| �[1;31mUnapproved�[0m | High CVE-2019-8457          | db5.3        | 5.3.28+dfsg1-0.5       | SQLite3 from 3.6.0 to and including 3.27.2 is                |
| �[1;31mUnapproved�[0m | High CVE-2019-25013         | glibc        | 2.28-10+deb10u1        | The iconv feature in the GNU C Library (aka                  |
| �[1;31mUnapproved�[0m | High CVE-2022-23219         | glibc        | 2.28-10+deb10u1        | The deprecated compatibility function clnt_create in         |
| �[1;31mUnapproved�[0m | High CVE-2022-23218         | glibc        | 2.28-10+deb10u1        | The deprecated compatibility function svcunix_create         |

Current build from debian 10. And there are HIGH: 17, CRITICAL: 4 vulnerabilities. Even debian 11 the latest there are 2 critical. Should we continue using debian? Damn, I can't use any image with critical and high vulnerability in my prod env.

[carrodher]

The Bitnami Application Catalog (OpenSource) is based on bitnami/minideb (Debian 10 at this moment although it will be updated to Debian 11 soon).
Apart from that, Bitnami, as part of VMware, provides a custom container and Helm Charts catalog based on the desired base image (generic distro such as Debian 10 & 11, CentOS 7, PhotonOS 3 & 4, Ubuntu 18.04 & 20.04, or custom golden image) through the VMware Tanzu Application Catalog.

[mirekphd]

It's not getting any better... high time to follow the open source community and replace Debian with Alpine, distroless, and Ubuntu. We had to switch away from all your containers to the open source ones (despite their other issues that required work) for that very reason... and today this prevented us from considering using bitnami/cassandra:4.0:

Listing most important vulnerabilities in bitnami-minideb:bullseye-clair-cve-scan-20220719-173817.txt:

Unapproved vulnerabilities:
| �[1;31mUnapproved�[0m | Critical CVE-2022-2068      | openssl      | 1.1.1n-0+deb11u2 | In addition to the c_rehash shell command injection          |
| �[1;31mUnapproved�[0m | High CVE-2019-8457          | db5.3        | 5.3.28+dfsg1-0.8 | SQLite3 from 3.6.0 to and including 

[marrws]

(...)

Unapproved vulnerabilities:
| �[1;31mUnapproved�[0m | Critical CVE-2022-2068      | openssl      | 1.1.1n-0+deb11u2 | In addition to the c_rehash shell command injection          |
| �[1;31mUnapproved�[0m | High CVE-2019-8457          | db5.3        | 5.3.28+dfsg1-0.8 | SQLite3 from 3.6.0 to and including 

CVE-2022-2068 is already fixed¹ on bullseye, you have to trigger apt-get update && apt-get upgrade to get the newer 1.1.1n-0+deb11u3 version.

I checked the mail list² for CVE-2019-8457 and there's no official statement about backporting the fix to bullseye. The security tacker says that sqlite3 is fixed but db5.3 not because it uses an embedded copy of sqlite3. Maybe you can uninstall db5.3 using apt-get purge if is not critical for your use case.

Footnotes

1. https://security-tracker.debian.org/tracker/CVE-2022-2068 ↩

2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010974#35 ↩