Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulnerabilities in the image #486

Open
kaiossoares opened this issue Aug 23, 2024 · 3 comments
Open

Vulnerabilities in the image #486

kaiossoares opened this issue Aug 23, 2024 · 3 comments

Comments

@kaiossoares
Copy link
Contributor

Hello everyone!

I recently had the need to scan the Docker images I use, using the Snyk tool, which is capable of identifying vulnerabilities.
So for timescaledb-ha it pointed out some versions of projects that are currently being used and have vulnerabilities. I believe the most important ones are the "High" ones, such as:

I would love to contribute, but I am also aware that switching versions may break some things. I have already done a fork the repository and am updating some versions of other projects that this image uses.
Any guidance on how this should be done would be greatly appreciated, I have also attached the full Snyk report.

report_snyk.txt

@sebastianvoss
Copy link

It seems there are also some CVEs with severity critical which do not come from the base image:

docker scout cves timescale/timescaledb-ha:pg16.4-ts2.16.1-all --ignore-base --only-severity critical

Output:

## Overview

                    │                   Analyzed Image
────────────────────┼─────────────────────────────────────────────────────
  Target            │  timescale/timescaledb-ha:pg16.4-ts2.16.1-all
    digest          │  17d28299169a
    platform        │ linux/arm64
    provenance      │ https://github.com/timescale/timescaledb-docker-ha
                    │  refs/heads/master
    vulnerabilities │    5C     0H     0M     0L
    size            │ 1.8 GB
    packages        │ 889


## Packages and Vulnerabilities

   3C     0H     0M     0L  stdlib 1.19.1
pkg:golang/[email protected]

    ✗ CRITICAL CVE-2024-24790
      https://scout.docker.com/v/CVE-2024-24790
      Affected range : <1.21.11
      Fixed version  : 1.21.11

    ✗ CRITICAL CVE-2023-24540
      https://scout.docker.com/v/CVE-2023-24540
      Affected range : <1.19.9
      Fixed version  : 1.19.9

    ✗ CRITICAL CVE-2023-24538
      https://scout.docker.com/v/CVE-2023-24538
      Affected range : <1.19.8
      Fixed version  : 1.19.8


   1C     0H     0M     0L  stdlib 1.20.12
pkg:golang/[email protected]

    ✗ CRITICAL CVE-2024-24790
      https://scout.docker.com/v/CVE-2024-24790
      Affected range : <1.21.11
      Fixed version  : 1.21.11


   1C     0H     0M     0L  stdlib 1.20.5
pkg:golang/[email protected]

    ✗ CRITICAL CVE-2024-24790
      https://scout.docker.com/v/CVE-2024-24790
      Affected range : <1.21.11
      Fixed version  : 1.21.11



5 vulnerabilities found in 3 packages
  LOW       0
  MEDIUM    0
  HIGH      0
  CRITICAL  5

@kaiossoares
Copy link
Contributor Author

Studying the report further, I saw that the vulnerability problem is in other projects, including "pgbouncer_exporter" and "pgbackrest_exporter".

So I forked the current repository and updated to the latest versions of these projects.

image

So, when building the image, I noticed a considerable reduction in vulnerabilities. But there is still a "High" point in "pgbouncer_exporter", where I believe that if a more recent release were released it would solve the problem, I am trying to contact the repository maintainers.

@saolof
Copy link

saolof commented Sep 20, 2024

If the CVE is in the Go stdlib, is building the exporters from source in a dockerfile step using a recent version of the go toolchain an option? The official prometheus exporters can all be built with an ordinary go build or go install <github link and tag> afaik, and don't need any build scripts.

Here's one example from a workshop I had with my team that uses a distroless base for the final image: https://github.com/saolof/container_image_workshop/blob/master/6_go_install_dockerfile/Dockerfile

Edit: ah, reading the filed issue on the pgbouncer exporter repo, it looks like the issue is golang.org/x/net/[email protected]. It looks like this got fixed in this commit on their master branch: prometheus-community/pgbouncer_exporter@220d739

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants