python:3.8-buster base images shows a lot of issues when scanned by ECR

[rpm-kevin]

My manager is having me look into the list of scanning Vulnerabilities in ECR, and when pushing up an image which is just apt-get upgrade and nothing more, it is reporting 23 Vulnerabilities. Since these are not related to our own Dockerfile or application stack, but rather upstream, I thought it being appropriate to post the issues here to be resolved. Below is a list provided by the ECR image scanner of all the issues detected in the base python:3.8-buster image provided via DockerHub as of this time of writing:

• bash: CVE-2019-18276
• gcc-8: CVE-2018-12886, CVE-2019-15847
• gnupg2: CVE-2019-14855
• libssh2-1: CVE-2019-17498, CVE-2019-13115
• perl: CVE-2011-4116
• tar: CVE-2019-9923, CVE-2005-2541
• login, passwd: CVE-2019-19882, CVE-2007-5686, CVE-2013-4235
• python2.7: CVE-2019-20907, CVE-2019-16935, CVE-2020-8492
• imagemagick: CVE-2019-16711, CVE-2019-16710, CVE-2019-16712, CVE-2019-16708, CVE-2019-16713, CVE-2020-10251
• expat: CVE-2013-0340
• coreutils: CVE-2016-2781

Thank you very much for your time and effort on creating and maintaining the Python 3.8 base Docker images.

Doing some additional research, it seems that AWS uses Clair for scanning: https://github.com/quay/clair

[wglambert]

All packages are up to date currently

$ docker run -it --rm python bash
Unable to find image 'python:latest' locally
latest: Pulling from library/python
0c6b8ff8c37e: Pull complete
412caad352a3: Pull complete
e6d3e61f7a50: Pull complete
461bb1d8c517: Pull complete
808edda3c2e8: Pull complete
40a42e6db467: Pull complete
2229fb06ed75: Pull complete
5bdc09405088: Pull complete
c26b91207ef4: Pull complete
Digest: sha256:d91af26d6b8e04ba382c28707188f30e2c1c5359993b3f535fcf1542fc1b7a30
Status: Downloaded newer image for python:latest
root@6e5e576dac81:/# apt update && apt upgrade
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB]
Get:3 http://security.debian.org/debian-security bullseye-security/main amd64 Packages [114 kB]
Get:4 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
Get:5 http://deb.debian.org/debian bullseye/main amd64 Packages [8183 kB]
Get:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [2596 B]
Fetched 8499 kB in 2s (5476 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

See also https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves
And docker-library/openjdk#449 (comment), docker-library/postgres#286 (comment) docker-library/openjdk#161, docker-library/openjdk#112, docker-library/postgres#286, docker-library/drupal#84, docker-library/official-images#2740, docker-library/ruby#117, docker-library/ruby#94, #152, docker-library/php#242, docker-library/buildpack-deps#46, docker-library/openjdk#185.

A CVE doesn't imply having an actual vulnerability, and often is even a false positive (given how most distributions handle versioning/security updates in stable releases). If there are actionable items we can resolve, we're happy to do so (and do so actively). We update all Debian based images to include any updates in apt packages at least monthly (we regenerate the base images and then rebuild all dependent images).

[rpm-kevin]

Thank you for that information, I'll double-check if I have the most recent version of the Docker image. I wasn't using the :latest tag however, I am using :3.8-buster.

[zifot]

FWIW Debian stable uses libexpat 2.2. And Python installed in the image is using that system version of the lib, instead of the one shipped with Python (which is now 2.4.x and contains many security fixes, e.g from 2.4.0 alone: https://github.com/libexpat/libexpat/blob/R_2_4_0/expat/Changes).

As far as I can see (I've checked source packages), fixes from libexpat 2.4.x are not backported to Debian stable.

Not sure if this is the best approach for the project here, but maybe you could consider building additional no-system-libraries versions of the images, that would not use --with-system- build flags?

I admit multitude of image versions could be confusing and we can never be sure that CPython will follow with updating those "fast enough", but on the other hand, at least for the libexpat, Python is much faster with doing that than Debian stable used in the images and current users are vulnerable for various attacks.

[tianon]

I don't think we should add additional variants (the added build load of that is pretty high, not to mention the added user confusion on which versions they should use), but I would definitely be willing to consider dropping the --with-system-... flags entirely.

My primary concern in doing so would be ensuring that Python does do timely releases when bundled dependencies have security issues -- does anyone know if there's an official policy from the project around that?

The system dependencies are attractive because I know (and have seen firsthand) that the Debian security team is very proactive about fixing security issues (although that almost never involves fixing them by bumping the version -- see https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves for some more well-thought-out description around that), and that the automatic rebuilds we get from the official images build pipeline thus pull in those Debian security fixes automatically without a Python bump (which is especially important/useful for those older Python versions that might be getting normal bumps less often).

[tianon]

https://discuss.python.org/t/vendoring-third-party-libraries-in-cpython/7844/2 is a useful post around this -- it basically mirrors my sentiment that perhaps this doesn't make sense here because security updates to bundled libraries are not necessarily a priority for them (I'm sure it's not a problem for the actively maintained branches, but for the older maintenance branches it's probably less likely).

[tianon]

https://security-tracker.debian.org/tracker/CVE-2013-0340 is a useful link for the listed expat CVE specifically with some useful notes from the Debian security team as to why it wasn't "fixed" in bullseye or older.