search

satori / go.uuid

UUID package for Go
MIT License
4.89k stars 601 forks source link

Fix Request: CVE-2021-3538 #123

Open bearaujus opened 1 year ago

bearaujus commented 1 year ago

Dependency go:github.com/satori/go.uuid:v1.2.0 is vulnerable CVE-2021-3538 9.8 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) vulnerability Results powered by Checkmarx(c)

hbelmiro commented 5 months ago

It seems it was already fixed in https://github.com/satori/go.uuid/commit/d91630c8510268e75203009fe7daf2b8e1d60c45. @satori can we have a new release with this fix?

cameracker commented 5 months ago

Hey guys, this package is totally dead. You're better of migrating.

nickdnk commented 2 months ago

I've been investigating this issue.

1.2.0 never included the vulnerable code. The vulnerability was introduced in a commit made after 1.2.0 was released (https://github.com/satori/go.uuid/commit/0ef6afb2f6cdd6cdaeee3885a95099c63f18fc8c), and no version was ever released after 1.2.0.

You should still migrate to an upgraded package, but as far as I can tell, 1.2.0 never had any problems (or, at least not the ones listed in the CVE).

cameracker commented 2 months ago

@nickdnk some additional context is that at the time the package manager ecosystem was in flux and there were a couple of tools that allowed users to easily use or "lock" to master. It should be said that's inadvisable, but there's a possibility of vulnerable versions in use in the wild.

I wonder if the posts clarifying the vulnerability are ultimately constructive. It bewilders me why people still use this package despite that huge amount of warning of it being abandonware and there being several superior replacements, some of which are drop in replacements. The greatest service the maintainer could do for the go community at this point would be to mark the repo archived and put it 6 feet under where it should be.

nickdnk commented 2 months ago

@nickdnk some additional context is that at the time the package manager ecosystem was in flux and there were a couple of tools that allowed users to easily use or "lock" to master. It should be said that's inadvisable, but there's a possibility of vulnerable versions in use in the wild.

I wonder if the posts clarifying the vulnerability are ultimately constructive. It bewilders me why people still use this package despite that huge amount of warning of it being abandonware and there being several superior replacements. The greatest service the maintainer could do for the go community at this point would be to mark the repo archived and put it 6 feet under where it should be.

Okay. I agree with not using it, however this is out of my control in my case. AWS is still using this package for some of their managed services (which I use), so I cannot do anything.

My main problem here is that the NIST publication is wrong. It lists this package as vulnerable "up until but excluding 1.2.0", which is just not true. The package was vulnerable, but that was after 1.2.0, only when using a non-tagged release/commit, and definitely not before it. This is giving me a compliance headache because it incorrectly comes up as a critical vulnerability for version 1.2.0.

I have informed NIST that their article gives a false impression of what happened.

cameracker commented 2 months ago

Do you think it's worth raising this with AWS? It seems like it'd be better for their customers and services to replace the package.

nickdnk commented 2 months ago

I did. They essentially just said that 1.2.0 is not vulnerable and no action is required -- which is true, however, it still comes up as a vulnerability when we scan our infrastructure. I have told them this as well and suggested they upgrade to https://github.com/gofrs/uuid to get rid of the problem entirely.

The point is just that 1.2.0 simply is not vulnerable and various scanners shouldn't list it as a a vulnerability, regardless if it's abandonware or not.

cameracker commented 2 months ago

Abandonware is a supply chain risk unto itself and it's disappointing they're taking the pedantic stance. NIST has a moderation issue for the NVD currently, so it'll be hit or miss whether you get movement on it. Sorry you're in this situation. I still hope people see issues like this and stop using the package.

nickdnk commented 2 months ago

Abandonware is a supply chain risk unto itself and it's disappointing they're taking the pedantic stance. NIST has a moderation issue for the NVD currently, so it'll be hit or miss whether you get movement on it. Sorry you're in this situation. I still hope people see issues like this and stop using the package.

Agreed, and what I meant was that 1.2.0 is not vulnerable to CVE-2021-3538 specifically.

Maybe some of them are reading this thread right now and considering an upgrade after I brought it up. Who knows.

I'm not sure what "a moderation issue for the NVD" means. I emailed them about it, they're looking into it they say.

nickdnk commented 2 months ago

Anecdotally, Github says this on their CVE page (if you click the link in my previous comment): "Unfortunately, the latest tagged release is vulnerable to this issue"

How is that true, when the latest tagged release is 1.2.0? And they reference 1.2.1 and some github commit as vulnerable versions. Was a tag deleted? This is so confusing.