Python: CRITICAL security vulnerability reported in image scan (python:3.7.4-slim-buster)

Created on 14 Aug 2019  路  8Comments  路  Source: docker-library/python

I am using python:3.7.4-slim-buster docker image for a python application which is a Linux based docker container image. I received the results from a BlackDuck (BD) image scan on my container image and has a reported _CRITICAL_ security vulnerability for BerkeleyDB 5.3.28. I was wondering if someone can help me suggest a way to solve the issue.
The BD report suggests upgrade from BerkeleyDB 5.3.28 to v6.2.31 will fix the vulnerability. Most recent being v18.1.32. Digging down into the root of the container I found libdb-5.3.so listed in the following dir:

root@08ad4950b59f:/usr/lib/x86_64-linux-gnu# ls
audit              libexpatw.so.1    liblz4.so.1         libsqlite3.so.0.8.6
coreutils          libexpatw.so.1.6.8    liblz4.so.1.8.3     libssl.so.1.1
engines-1.1        libffi.so.6       libmenuw.so.6       libstdc++.so.6
gconv              libffi.so.6.0.4   libmenuw.so.6.1     libstdc++.so.6.0.25
libacl.so.1        libformw.so.6     libnettle.so.6      libtasn1.so.6
libacl.so.1.1.2253     libformw.so.6.1   libnettle.so.6.5    libtasn1.so.6.5.5
libapt-pkg.so.5.0      libgdbm.so.6      libp11-kit.so.0     libtic.so.6
libapt-pkg.so.5.0.2    libgdbm.so.6.0.0  libp11-kit.so.0.3.0     libtic.so.6.1
libapt-private.so.0.0      libgmp.so.10      libpanelw.so.6      libunistring.so.2
libapt-private.so.0.0.0    libgmp.so.10.3.2  libpanelw.so.6.1    libunistring.so.2.1.0
libattr.so.1           libgnutls.so.30   libpcreposix.so.3   libzstd.so.1
libattr.so.1.1.2448    libgnutls.so.30.23.2  libpcreposix.so.3.13.3  libzstd.so.1.3.8
libcrypto.so.1.1       libhogweed.so.4   libseccomp.so.2     perl
libdb-5.3.so           libhogweed.so.4.5     libseccomp.so.2.3.3     perl-base
libdebconfclient.so.0      libidn2.so.0      libsemanage.so.1
libdebconfclient.so.0.0.0  libidn2.so.0.3.4  libsqlite3.so.0

Also, the BD report lists the following as the source of the vulN:

debian libdb5.3/5.3.28+dfsg1-0.5/amd64

I wonder what is a way to upgrade this package called BerkeleyDB and how can it be done. Thanks in advance for any help on this matter.

question

Most helpful comment

I sorted through the full list, and only the following two are even remotely relevant to Debian / the referenced image:

In other words, I don't see anything in that report that isn't a false positive. :confused:

All 8 comments

Do you have a specific CVE number or other identifier that would help us chase this down?

$ docker pull python:3.7-slim-buster
3.7-slim-buster: Pulling from library/python
Digest: sha256:4b0cd7cc8a201bd8098adbb2f2ffef55eec1364297b0c1c6630cc4dee41739e3
Status: Downloaded newer image for python:3.7-slim-buster

$ docker run -it --rm python:3.7-slim-buster bash
root@6b90558f8f0f:/# apt-get update -qq
root@6b90558f8f0f:/# apt-get install libdb5.3
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libdb5.3 is already the newest version (5.3.28+dfsg1-0.5).
libdb5.3 set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@6b90558f8f0f:/# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Here are the 48 vulnerabilities found by BlackDuck for BerkeleyDB 5.3.28
VulNs-BerkeleyDB5.3.28.pdf
Hope this helps.

Extracted from the PDF for easier evaluation (with the actual relevant Debian security tracker links):

I sorted through the full list, and only the following two are even remotely relevant to Debian / the referenced image:

In other words, I don't see anything in that report that isn't a false positive. :confused:

I agree a lot of this might be false positives, but company policy mandates rectifying critical findings :roll_eyes: Any way you can suggest we can update the BerkeleyDB package to 6.2.31 or higher on our end?

I don't know of a way to do so without breaking things; I'd recommend
contacting Black Duck and asking them if they can fix these detections that
don't apply.

Ok fair enough. One last favor, can you take a look at the following list? We have two more critical vulnerabilities for Sqllite and Perl:

http://sqlite.org/
SQLite3.27.2
Versions:417
Columns: Identifier, Published, Base Score, Exploitability, Impact
NVD CVE-2017-10989          Jul 7, 2017 7.5 10  6.4
NVD CVE-2017-2519           May 22, 2017    7.5 10  6.4
NVD CVE-2017-2518           May 22, 2017    7.5 10  6.4
NVD CVE-2017-2520           May 22, 2017    7.5 10  6.4
NVD CVE-2018-20506          Apr 3, 2019 6.8 8.6 6.4
NVD CVE-2018-20346          Dec 21, 2018    6.8 8.6 6.4
BDSA BDSA-2019-2110 (CVE-2019-5827) Jul 16, 2019    6.8 8.6 6.4
BDSA BDSA-2019-2130         Jul 16, 2019    5.8 8.6 4.9
BDSA BDSA-2019-0814 (CVE-2019-9936) Mar 26, 2019    5   10  2.9
BDSA BDSA-2019-1682 (CVE-2019-8457) Jun 3, 2019 5   10  2.9
BDSA BDSA-2019-1472 (CVE-2019-5018) May 13, 2019    5   10  2.9
NVD CVE-2018-20505          Apr 3, 2019 5   10  2.9
BDSA BDSA-2019-2131         Jul 16, 2019    5   10  2.9
BDSA BDSA-2019-0813 (CVE-2019-9937) Mar 25, 2019    5   10  2.9
NVD CVE-2016-6153           Sep 26, 2016    4.6 3.9 6.4
BDSA BDSA-2019-2132         Jul 16, 2019    4.6 3.9 6.4
NVD CVE-2017-13685          Aug 29, 2017    4.3 8.6 2.9


http://www.perl.org/
Perl5.28.0
Versions:1269
Columns: Identifier, Published, Base Score, Exploitability, Impact
NVD CVE-2018-18314          Dec 7, 2018 7.5 10  6.4
BDSA BDSA-2018-4215 (CVE-2018-18311)    Dec 5, 2018 6.4 10  4.9
NVD CVE-2018-18313          Dec 7, 2018 6.4 10  4.9
BDSA BDSA-2018-4217 (CVE-2018-18312)    Dec 5, 2018 5.1 4.9 6.4

I am still in process to work on these, but in most likelihood these are false positives as well. It will be great to have an assurance from the docker team. Helps rest my case :stuck_out_tongue_closed_eyes:

If those are in this same image, you'll want to look up the CVEs on https://security-tracker.debian.org/tracker/ to check their applicability (just as I've done above).

See also https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves for more information/tips.

Was this page helpful?
0 / 5 - 0 ratings