wglambert
commented
1 year ago https://security-tracker.debian.org/tracker/CVE-2021-46848 Buster and Bullseye aren't fixed yet, it's also considered a minor issue by the Debian Security Team
https://security-tracker.debian.org/tracker/CVE-2019-8457 For db5.3 Buster and Bullseye aren't fixed yet, it's also considered a minor issue by the Debian Security Team
Background:
Tags in the [official-images] library file[s] are only built through an update to that library file [–like if the Dockerfile is updated–] or as a result of its base image being updated (ie, an image
FROM debian:busterwould be rebuilt whendebian:busteris built).
Official Images FAQ:
Though not every CVE is removed from the images, we take CVEs seriously and try to ensure that images contain the most up-to-date packages available within a reasonable time frame
Since our build system makes heavy use of Docker build cache, just rebuilding the all of the Dockerfiles won't cause any change. So we rely on periodic base image updates.
We strive to publish updated images at least monthly for Debian. We also rebuild earlier if there is a critical security need. Many Official Images are maintained by the community or their respective upstream projects, like Ubuntu, Alpine, and Oracle Linux, and are subject to their own maintenance schedule.
- from the same FAQ link
Describe the bug We are using redis:70.4-bullseye image and found vulnerabilities in security scans of redis image.
A short description of the bug.
7.0.4-bullseye: Pulling from library/redis Digest: sha256:091a7b5de688f283b30a4942280b64cf822bbdab0abfb2d2ce6db989f2d3c3f4 Status: Image is up to date for redis:7.0.4-bullseye docker.io/library/redis:7.0.4-bullseye 2022-11-30T06:20:12.917-0500 �[34mINFO�[0m Detected OS: debian 2022-11-30T06:20:12.917-0500 �[34mINFO�[0m Detecting Debian vulnerabilities... 2022-11-30T06:20:13.000-0500 �[34mINFO�[0m Number of PL dependency files: 1 2022-11-30T06:20:13.000-0500 �[34mINFO�[0m Detecting gobinary vulnerabilities...
redis:7.0.4-bullseye (debian 11.5)
Vulnerabilites found.... +------------------+------------------+----------+-------------------+------------------+-----------------------------------------+ | LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE | +------------------+------------------+----------+-------------------+------------------+-----------------------------------------+ ------------------+------------------+----------+-------------------+------------------+-----------------------------------------+ | libtasn1-6 | https://github.com/advisories/GHSA-6468-68pw-9chw | CRITICAL | 4.16.0-2 | | libtasn1: Out-of-bound | | | | | | | access in ETYPE_OK | | | | | | | -->avd.aquasec.com/nvd/https://github.com/advisories/GHSA-6468-68pw-9chw | +------------------+------------------+----------+-------------------+------------------+-----------------------------------------+ | libdb5.3 | https://github.com/advisories/GHSA-p4jx-5p2x-4pq7 | CRITICAL | 5.3.28+dfsg1-0.8 | | sqlite: heap out-of-bound | | | | | | | read in function rtreenode() | | | | | | | -->avd.aquasec.com/nvd/https://github.com/advisories/GHSA-p4jx-5p2x-4pq7 | +------------------+------------------+----------+-------------------+------------------+-----------------------------------------+
To reproduce
Steps to reproduce the behavior and/or a minimal code sample.
we can use the following link to reproduce the CVE https://trivy.dev/results/?image=redis:7.0.4-bullseye
Expected behavior
A description of what you expected to happen. https://github.com/advisories/GHSA-p4jx-5p2x-4pq7 is fixed in latest version of the sqlite package. Will it be fixed in future release or any work around?
Additional information
Any additional information that is relevant to the problem.