CVE-2021-3538 incorrectly lists "latest tag as vulnerable"

[nickdnk]

Hello

I've been investigating this CVE after a compliance issue at AWS. They still use the package for some internal services, but they use 1.2.0, which does not have any vulnerabilities. However, I keep getting warnings about this CVE.

1.2.0 (latest) does not have this vulnerability: The vulnerability was introduced in a commit made after 1.2.0, and a version with the vulnerability was never released. The package is dead and replacements are suggested, however the CVE should still correctly indicate what's actually happening.

All of this has led to some confusion for me, and the reporting on this issue is inconsistent and sometimes straight up incorrect. For instance, NIST list the package as vulnerable "up until but excluding 1.2.0", which is not true: https://nvd.nist.gov/vuln/detail/CVE-2021-3538#range-12450093, while still explaining which two commits introduced and fixed the issue:

A flaw was found in github.com/satori/go.uuid in versions from commit 0ef6afb2f6cdd6cdaeee3885a95099c63f18fc8c to d91630c8510268e75203009fe7daf2b8e1d60c45. Due to insecure randomness in the g.rand.Read function the generated UUIDs are predictable for an attacker.

Both of these commits were made after 1.2.0. See https://github.com/satori/go.uuid/commits/master/ - 1.2.0 is commit f58768cc1a7a7e77a3bd49e98cdd21419399b6a3.

And the Github CVE database lists the "latest tagged release" as vulnerable, which is 1.2.0 and hence also not true: GHSA-33m6-q9v5-62r7.

I'm well aware this is ancient, but the code I'm auditing is not something I own or control, so I cannot compel them to change a package that technically does not have this vulnerability.

Note also that no version 1.2.1 exists.

[DrDaveD]

I don't understand what you are asking us to do?

It's interesting that the vulnerability must never a have actually been in sif either, because prior to the announced fix it was using satori/go.uuid 1.2.0.

Note also that no version 1.2.1 exists.

I see, but apptainer/sif starting in 1.2.2 (a coincidentally similar version, confused me at first) selects a specific commit in satori/go.uuid after the fix was committed there.

Also note that starting in sif 2.0.0, satori/go.uuid isn't even used anymore.

[nickdnk]

I'm sorry, I see I wasn't quite clear.

The post says "Unfortunately, the latest tagged release is vulnerable to this issue" - this isn't true. No tagged release from that repo is vulnerable because the vulnerability was introduced on the master branch only and should never have made it into any systems. I'm not too familiar with the Go ecosystem, but I'm assuming that people mainly use versioned releases. Sticking to a specific commit, of course, would cause this problem to appear in the wild, but I'm not sure why you'd do that.

This confusion probably stems from 1.2.0 being labeled as vulnerable in NIST, which is also incorrect.

I guess all I'm asking you to do is revise the text that explains the affected versions.

I'm also well aware this is ancient history and nobody should be using the package, but currently I'm auditing systems that have it as a third party dependency in a managed service on AWS. AWS does not want to update it (for some reason), so I'm trying to instead make the CVE actually report things correctly as the vulnerability does not exist on 1.2.0.

[DrDaveD]

I see. The weird thing is that if we would update the text to be accurate, then it turns out there's no need for the advisory at all because sif never used a vulnerable version. That's pretty hard to explain as a revision. We could I suppose add an update section on the beginning, leaving the original text unchanged. Would that do?

Also, it looks like we don't have edit access to the advisory under https://github.com/advisories that you linked to. We do have access to our own copy referenced at https://github.com/apptainer/sif/security/advisories. I think there is a way to request that github update their copy from our copy, however. I successfully did that once on an apptainer advisory where I added an addendum and convinced github to add it also to their copy.

Btw apptainer/sif is a fork of sylabs/sif which has the same text on their advisory, if you care about that. It looks like the fork happened between the 1.2.1 and 1.2.2 releases of apptainer/sif. (For the record, apptainer/apptainer is not a fork from sylabs, but the reverse, sylabs/singularity is a fork of apptainer/singularity).

[nickdnk]

I'm unsure, really. I have zero experience with CVE policy or procedures. I just wanted to let you know, since the CVE on Github said to create an issue here if there were questions or comments on the advisory.

I have contacted NIST and asked them to revise their CVE listing to not include 1.2.0 (or any other version, really), as that could potentially solve this problem. At this time I have also dedicated way more time to this than it merits, since it's not a dependency I use directly nor have any control over. I informed AWS, and they advised me that 1.2.0 was not vulnerable and no action was required, even though that does not silence (their own) AWS Inspector service.

Bottom line is that this is strictly a bureaucratic issue now, and as you can see from the number of referenced issues in satori/go.uuid#73, it has had quite a ripple effect on packages and projects that were probably never vulnerable to begin with.

[DrDaveD]

I updated the description in the project copy and requested in github/advisory-database#4822 to update the github copy.

[nickdnk]

Hello Dave

NIST has informed me today that they have revised their publication, and 1.2.0 is no longer listed as an affected version: https://nvd.nist.gov/vuln/detail/CVE-2021-3538 - now only the commits are listed.