Grype is showing all critical vulnerabilities even in latest gitlab-ce 17.5.0 docker image are not fixed :(

Grype
1

I’m reaching out for assistance as I’ve been scanning the latest images using Grype, and it continues to report multiple critical vulnerabilities. This issue also persisted with previous image versions, specifically 17.4.X and 17.3.X.

Additionally, I encountered a warning message:

WARN could not match by package language (package=Pkg(type=gem, name=gitlab-security_report_schemas, version=0.1.2.min15.0.0.max15.2.0, upstreams=0)): matcher failed to parse version pkg=“gitlab-security_report_schemas” ver=“0.1.2”

I’m trying to understand what this warning means and whether it impacts the reliability of the vulnerability reports. Should I assume that the reported critical vulnerabilities, such as CVE-2021-23369, are potentially false positives, given that they have been reported for some time without resolution?

Any insights or guidance on how to proceed would be greatly appreciated.

Thanks
Manish

2

I just ran grype gitlab/gitlab-ce:17.5.1-ce.0 and it found the CVE you mentioned - CVE-2021-23369 / GHSA-f2jv-r9rf-7988 (among many others).

handlebars 1.0.0 3.0.8 npm GHSA-w457-6q6x-cgp9  Critical
handlebars 1.0.0 4.7.7 npm GHSA-f2jv-r9rf-7988  Critical
handlebars 1.0.0 4.7.7 npm GHSA-765h-qjxv-5f44  Critical
handlebars 1.0.0 3.0.7 npm GHSA-q42p-pg8m-cqh6  High
handlebars 1.0.0 3.0.8 npm GHSA-q2c6-c6pm-g3gh  High
handlebars 1.0.0 3.0.8 npm GHSA-g9r4-xpmj-mj65  High
handlebars 1.0.0 3.0.8 npm GHSA-3cqr-58rm-57f8  High
handlebars 1.0.0 3.0.8 npm GHSA-2cf5-4w76-r9qv  High
handlebars 1.0.0 4.0.0 npm GHSA-9prh-257w-9277  Medium

There’s an upstream bug for GitLab here. I don’t know why they closed it. But it certainly seems like the issue is still in the images, and thus not a false positive.

Edit: It looks like there are vscode plugins that we may be mis-identifying as npm packages, perhaps.

3

Hi @Manish2481983 thanks so much for the report!

I’m trying to understand exactly what you’re seeing. I think you are running grype on public GitLab CE images from dockerhub, like this:

grype gitlab/gitlab-ce:17.5.0-ce.0

And you’re surprised to see that some critical CVEs are present in several versions, specifically gitlab/gitlab-ce:17.3.6-ce.0, gitlab/gitlab-ce:17.4.3-ce.0, and gitlab/gitlab-ce:17.5.1-ce.0 from https://hub.docker.com/r/gitlab/gitlab-ce/tags. Is that right? The rest of my answer assumes that’s what you’re doing, so let me know if I got that wrong :slight_smile:

I think you have a couple of questions:

  1. Are these critical vulnerabilities, especially CVE-2021-23369 really present?
  2. What do the warnings like WARN could not match by package language mean? Do they mean the critical vulns are false positives?

I’ll start with the warnings:

[0002] WARN could not match by package language (package=Pkg(type=gem, name=gitlab-security_report_schemas, version=0.1.2.min15.0.0.max15.2.0, upstreams=0)): matcher failed to parse version pkg=“gitlab-security_report_schemas” ver=“0.1.2.min15.0.0.max15.2.0”: unable to create semver obj: Malformed version: 0.1.2.min15.0.0.max15.2.0

This means that Grype found package that looks like a Ruby Gem but that has a version Grype can’t understand how to compare, namely 0.1.2.min15.0.0.max15.2.0. There are no matches on that package, or on the other packages producing this warning, so this is not the cause of any false positives.

False Positives

I think there are false positives in the image, because Syft is finding the package.json files from VS Code extensions and treating them like NPM packages.

Taking a look at Remote code execution in handlebars when compiling templates · CVE-2021-23369 · GitHub Advisory Database · GitHub, this vulnerability is against the NPM package handlebars, but not the VS Code extension. Let’s run Syft on the image to see what it finds:

❯ syft -o json gitlab/gitlab-ce:17.4.3-ce.0 > gitlab.17.4.3-ce.0.syft.json
❯ cat gitlab.17.4.3-ce.0.syft.json| \
jq '.artifacts[] | select(.name == "handlebars") | .locations[] | .path'
"/opt/gitlab/embedded/service/gitlab-rails/public/assets/webpack/gitlab-vscode/0.0.1-dev-20240909013227/vscode/extensions/handlebars/package.json"
❯ head handlebars.json
{
  "name": "handlebars",
  "displayName": "%displayName%",
  "description": "%description%",
  "version": "1.0.0",
  "publisher": "vscode",
  "license": "MIT",
  "engines": {
    "vscode": "0.10.x"
  },

So it looks like Syft is seeing the package.json that is part of the VS Code extension for working on handlebars files, and thinking it is from the NPM package of the same name, which would be vulnerable to this CVE in version 1.0.0, so that particular vulnerability (CVE-2021-23369) is a false positive.

I’ll open a bug in Syft for this an post a link in a moment.

1 Like
4

Here’s a bug report in Syft that you can follow for updates: bug: stop reporting VSCode extensions as NPM packages · Issue #3381 · anchore/syft · GitHub

Basically, once that Syft bug is fixed and then a version of Grype is released that includes the fixed Syft, I believe this type of false positive will go away.

Thanks again for the report @Manish2481983! Have I answered your questions? Are there other questions you have about these scan results?

2 Likes
5

Thanks for the detailed explanation! @willmurphy
Yes, you’re correct that I ran Grype on the GitLab CE images from Docker Hub. Tried most of them.

  1. It seems there are indeed critical CVEs listed, including CVE-2021-23369, but I appreciate your insights on the potential false positives, particularly related to the VS Code extension. It’s good to know that the vulnerabilities might not apply directly to the packages found in the GitLab images.
  2. I understand now that the warnings about not matching by package language indicate that Grype encountered a version format it couldn’t parse, which doesn’t contribute to the false positives.

however there are more others vulns and assumed those are false positive
GitHub - moby/moby: The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems v25.0.1+incompatible 25.0.6 go-module GHSA-v23v-6jw2-98fq Critical
GitHub - moby/moby: The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems v27.0.3+incompatible 27.1.1 go-module GHSA-v23v-6jw2-98fq Critical

1 Like
6

I’ll go through all the critical vulns that aren’t about handlebars real quick:

❯ cat gitlab.17.4.3-ce.0.grype.json| jq '.matches[] | select(.vulnerability.severity == "Critical") | { package: .artifact.name, type: .artifact.type, cve: .vulnerability.id, location: .artifact.locations[0].path } | select(.package != "handlebars")'
{
  "package": "github.com/docker/docker",
  "type": "go-module",
  "cve": "GHSA-v23v-6jw2-98fq",
  "location": "/opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/devfile-0.0.28.pre.alpha1-x86_64-linux/bin/devfile"
}
{
  "package": "github.com/docker/docker",
  "type": "go-module",
  "cve": "GHSA-v23v-6jw2-98fq",
  "location": "/opt/gitlab/embedded/bin/prometheus"
}
{
  "package": "stdlib",
  "type": "go-module",
  "cve": "CVE-2024-24790",
  "location": "/opt/gitlab/embedded/bin/mattermost"
}
{
  "package": "stdlib",
  "type": "go-module",
  "cve": "CVE-2024-24790",
  "location": "/opt/gitlab/embedded/bin/mmctl"
}

So there are basically 2 remaining vulnerabilities:

  1. Authz zero length regression · CVE-2024-41110 · GitHub Advisory Database · GitHub
  2. NVD - CVE-2024-24790

Talking about GHSA-v23v-6jw2-98fq first: The vulnerability is in the Docker engine, but is reported against the Docker package (github.com/docker/docker). There are a couple Go binaries in the image that include vulnerable versions of the Docker code. I don’t know whether these libraries are being used in a way that an AuthZ bug affects the container. I would probably rule this a true positive because the vulnerable code seems to be present in the image, and I don’t have a good way of knowing whether it is or isn’t being invoked. I’d sort of be surprised if it’s being used that way, but I think the vulnerable code is present.

Now talking about CVE-2024-24790: This is a CVE against the Go standard library. When Go binaries are built, a copy of the Go runtime and standard library is included. GO-2024-2887 - Go Packages indicates that this is a bug in net/netip address resolution. Go executables compiled with Go older than 1.21.11 have the vulnerability, and the mattermost binary in the image meets that criteria, so this is also a true positive; the vulnerable code is present.

Of course, the real question you have is: Are these images actually vulnerable / insecure? The answer is: it depends how the vulnerable code is being used. But the vulnerability tools are telling you that the vulnerable code is present in the image, and Grype seems to be correct, except in the case of the handlebars package.

2 Likes
7

Thanks again !!! @willmurphy for the detailed breakdown. I appreciate your insights on both vulnerabilities.

For GHSA-v23v-6jw2-98fq, I agree that labeling it a true positive makes sense, especially given the presence of vulnerable code in the Docker image. It’s always tricky when we can’t definitively determine if the code is being invoked, but the potential risk can’t be ignored.

Regarding CVE-2024-24790, the fact that the Mattermost binary is built with an older version of Go does raise concerns. It’s critical to assess how that code is being used in the application context to gauge actual exposure.

In both cases, it seems prudent to evaluate the usage patterns of these binaries and we will consider updating or patching where possible. however we noticed that all these still present in latest gitlab-ce docker images.

1 Like