10000 False positive: CVE-2021-46848 detected on patched version of libtasn · Issue #2620 · anchore/grype · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

False positive: CVE-2021-46848 detected on patched version of libtasn #2620

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.

Sign up for GitHub

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

Jump to bottom
Open
dbrugman opened this issue Apr 25, 2025 · 4 comments
Open

False positive: CVE-2021-46848 detected on patched version of libtasn #2620

dbrugman opened this issue Apr 25, 2025 · 4 comments
Labels
bug Something isn't working false-positive

Comments

@dbrugman
Copy link

What happened:
Vulnerability CVE-2021-46848 was detected on a Docker image. The impacted component was libtasn1-6:4.19.0-2 (deb package, Ubuntu based image). However, this vulnerability only impacts versions < 4.19.0 of this library: https://ubuntu.com/security/CVE-2021-46848#notes.

Quote: "GNU Libtasn1 before 4.19.0 has an ETYPE_OK off-by-one array size check that affects asn1_encode_simple_der."

Note that Ubuntu classifies this as a Low priority issue, while NVD rated this as a Critical vulnerability. Since we standardize on NVD scores, this causes a Critical false positive for us.

What you expected to happen:
Since the library is not impacted I expected this not to be detected as a vulnerability.

How to reproduce it (as minimally and precisely as possible):
Run:

grype --by-cve grafana/agent:v0.38.0 | grep CVE-2021-46848`

This will result in:

libtasn1-6 ... 4.19.0-2 ... deb ... CVE-2021-46848 ... Low

Anything else we need to know?:
n/a

Environment:
@dbrugman dbrugman added the bug Something isn't working label Apr 25, 2025
@popey
Copy link
Contributor
popey commented Apr 25, 2025

Thanks for filing the issue @dbrugman

A few things come up:

That container is a year old according to dockerhub. You're about 20 releases behind the latest which is v0.44.2.

As a result of being old, that container is also built on an unsupported (non LTS) version of Ubuntu.

syft -o json grafana/agent:v0.38.0 | jq .distro
 ✔ Loaded image grafana/agent:v0.38.0
 ✔ Parsed image sha256:c61b9dfa6269c16041dd3bc9228da8d8463a043d29fe79005fa677bce4a8d116
 ✔ Cataloged contents 3d9ce9a151ad5e06eb133903f78053b71301ddf205335098390838b15fa2437a
   ├── ✔ Packages                        [680 packages]
   ├── ✔ File metadata                   [2,914 locations]
   ├── ✔ Executables                     [727 executables]
   └── ✔ File digests                    [2,914 files]
{
  "prettyName": "Ubuntu 23.04",
  "name": "Ubuntu",
  "id": "ubuntu",
  "idLike": [
    "debian"
  ],
  "version": "23.04 (Lunar Lobster)",
  "versionID": "23.04",
  "versionCodename": "lunar",
  "homeURL": "https://www.ubuntu.com/",
  "supportURL": "https://help.ubuntu.com/",
  "bugReportURL": "https://bugs.launchpad.net/ubuntu/",
  "privacyPolicyURL": "https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
}

So, aside from this bug, I would recommend you update to a more modern grafana agent. v0.44.2 doesn't have this vulnerability.

grype --by-cve grafana/agent:v0.44.2 | grep CVE-2021-46848
 ✔ Loaded image                                                                                                                                                            grafana/agent:v0.44.2
 ✔ Parsed image                                                                                                          sha256:5529e078ab2d1cf66dd2d89dd07b6027cb3cac236005ae7afaf661c912b62c1e
 ✔ Cataloged contents                                                                                                           70e9a3a78efd95c06d4590e49bd5e899aadb5a8d1adc4f96b1b611e48fb27a6d
   ├── ✔ Packages                        [707 packages]
   ├── ✔ File metadata                   [2,915 locations]
   ├── ✔ Executables                     [724 executables]
   └── ✔ File digests                    [2,915 files]
 ✔ Scanned for vulnerabilities     [40 vulnerability matches]
   ├── by severity: 1 critical, 4 high, 22 medium, 11 low, 2 negligible
   └── by status:   23 fixed, 17 not-fixed, 0 ignored

... and uses a more modern (and supported) release of Ubuntu as a base.

syft -o json grafana/agent:v0.44.2 | jq .distro
 ✔ Loaded image                                                                                                                                                            grafana/agent:v0.44.2
 ✔ Parsed image                                                                                                          sha256:5529e078ab2d1cf66dd2d89dd07b6027cb3cac236005ae7afaf661c912b62c1e
 ✔ Cataloged contents                                                                                                           70e9a3a78efd95c06d4590e49bd5e899aadb5a8d1adc4f96b1b611e48fb27a6d
   ├── ✔ Packages                        [707 packages]
   ├── ✔ File metadata                   [2,915 locations]
   ├── ✔ Executables                     [724 executables]
   └── ✔ File digests                    [2,915 files]
{
  "prettyName": "Ubuntu 24.04.1 LTS",
  "name": "Ubuntu",
  "id": "ubuntu",
  "idLike": [
    "debian"
  ],
  "version": "24.04.1 LTS (Noble Numbat)",
  "versionID": "24.04",
  "versionCodename": "noble",
  "homeURL": "https://www.ubuntu.com/",
  "supportURL": "https://help.ubuntu.com/",
  "bugReportURL": "https://bugs.launchpad.net/ubuntu/",
  "privacyPolicyURL": "https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
}

We consider 'out of support' entries in the grype database as potentially vulnerable too.

@chovanecadam
Copy link
Contributor

Hi @popey, asking for a quick clarification -- is my understanding correct that Grype marks packages from EOL versions of Linux distributions as potentially vulnerable AND that this report is is a valid false positive that should not be reported as vulnerable?

@dbrugman
Copy link
Author
dbrugman commented May 2, 2025 •
edited
Loading

Thanks @popey - I'm very much aware of this image being very old. We keep a large catalog of SBOMs of all our current and previous images, and scan all those SBOMs for vulnerabilities on a daily basis. The resulting data sets are normalized in a relational schema which we use for our vulnerability dashboard. As a consequence of this false positive in combination with the relational schema, now all images in our catalog that use the same version of libtasn (which would otherwise not be flagged as vulnerable by Grype) will now show up as a Critical vulnerability on our Dashboard.

Anyways - thanks a lot for taking the time to look into this and the comprehensive answer.

BTW:

We consider 'out of support' entries in the grype database as potentially vulnerable too.

I fully agree with this

@wagoodman
Copy link
Contributor
wagoodman commented May 5, 2025 •
edited
Loading

I feel like this would be a good vunnel / grype-db enhancement; What I'm seeing on the canonical side of this is they either have no triaged this or they've declared this EOL. Today we still write these records in but leave the version constraints blank (thus it will match with any version):

$ grype db search CVE-2021-46848 --provider ubuntu

VULNERABILITY   PACKAGE     ECOSYSTEM  NAMESPACE                   VERSION CONSTRAINT
CVE-2021-46848  libtasn1-6  deb        ubuntu:distro:ubuntu:14.04
CVE-2021-46848  libtasn1-6  deb        ubuntu:distro:ubuntu:16.04
CVE-2021-46848  libtasn1-6  deb        ubuntu:distro:ubuntu:18.04
CVE-2021-46848  libtasn1-6  deb        ubuntu:distro:ubuntu:20.04
CVE-2021-46848  libtasn1-6  deb        ubuntu:distro:ubuntu:22.04
CVE-2021-46848  libtasn1-6  deb        ubuntu:distro:ubuntu:22.10
CVE-2021-46848  libtasn1-6  deb        ubuntu:distro:ubuntu:23.04

But, I agree the NVD record does have the information we need:

Image

What we should start doing is to let grype-db fill potentially missing data based off of the status of the ubuntu record (e.g. "needs-triage" or "EOL") and what we find on the NVD record (i.e. < 4.19.0 is vulnerable).

Note: the suggestion is not to do this at matching time, but instead, when writing the record into the DB. I think the hard part here is going to make certain we're selecting the CPE record from the NVD node configuration that accurately represents package described by the ubuntu record.

Created anchore/grype-db#568 to encapsulate this work --there are probably more cases across more providers.

@wagoodman wagoodman moved this to Ready in OSS May 5, 2025
@wagoodman wagoodman mentioned this issue May 5, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working false-positive
Projects
OSS
Status: Ready
Milestone
No milestone
Development

No branches or pull requests
4 participants
@wagoodman @popey @dbrugman @chovanecadam
0