[Vuln] High Severity Vulnerability found in Smallstep certificates library

[hrithiky-777]

Hi Team,

We have identified high risk vulnerability in our service, which uses your library https://github.com/smallstep/certificates
The vulnerability is related to protobuf component, which is a transitive dependency bought into smallstep certificates by Badger DB.

The badger DB version that you’re using here https://github.com/smallstep/certificates/blob/master/go.mod are github.com/dgraph-io/badger v1.6.2, github.com/dgraph-io/badger/v2 v2.2007.4
These are using older protobuf implementations which are not maintained currently as mentioned here https://github.com/golang/protobuf

Here's the flow:
github.com/smallstep/certificates v0.28.4
↓
github.com/dgraph-io/badger v1.6.2 ← Database storage library
↓
github.com/golang/protobuf v1.3.1 ← OLD VULNERABLE VERSION

• The vulnerability exists even with this one (github.com/golang/protobuf v1.5.3) and the corresponding CVE is https://nvd.nist.gov/vuln/detail/CVE-2024-24786

• Upon further checking, the latest version of protobuf library: https://github.com/protocolbuffers/protobuf-go v1.36.7 does not have any vulnerabilities associated with it.

• The latest version of badger https://github.com/hypermodeinc/badger/blob/main/go.mod is already using 1.36.6 version of protobuf and even this one doesn’t have any vulnerabilities.

Kindly requesting the smallstep team to please update the badger DB version so that these high severity vulnerabilities can be completely removed.

Please let me know if there are any challenges involved in this process, any reason this was not updated to maintain backward compatibility etc.
If there’s no problem, by when can we expect a new release which fixes this.

[hslatman]

Hey @hrithiky-777,

Thank you for opening the issue, and for sending the email the other day.

Hi Team,

We have identified high risk vulnerability in our service, which uses your library https://github.com/smallstep/certificates The vulnerability is related to protobuf component, which is a transitive dependency bought into smallstep certificates by Badger DB.

The badger DB version that you’re using here https://github.com/smallstep/certificates/blob/master/go.mod are github.com/dgraph-io/badger v1.6.2, github.com/dgraph-io/badger/v2 v2.2007.4 These are using older protobuf implementations which are not maintained currently as mentioned here https://github.com/golang/protobuf

Here's the flow: github.com/smallstep/certificates v0.28.4 ↓ github.com/dgraph-io/badger v1.6.2 ← Database storage library ↓ github.com/golang/protobuf v1.3.1 ← OLD VULNERABLE VERSION

* The vulnerability exists even with this one (`github.com/golang/protobuf v1.5.3`) and the corresponding CVE is  `https://nvd.nist.gov/vuln/detail/CVE-2024-24786`

* Upon further checking, the latest version of protobuf library: `https://github.com/protocolbuffers/protobuf-go` v1.36.7 does not have any vulnerabilities associated with it.

* The latest version of badger `https://github.com/hypermodeinc/badger/blob/main/go.mod` is already using 1.36.6 version of protobuf and even this one doesn’t have any vulnerabilities.

We've done some analysis ourselves, and come to the conclusion that this is most likely a false positive. We've built a few reproducer test programs relying on Badger v1 and v2, which resulted in compiled programs that don't include the offending protojson.Unmarshal call. We verified our results using govulncheck, which resulted in no vulnerabilities being reported. Notably, it calls out explicitly that "your code doesn't appear to call these vulnerabilities". We also created some intentionally vulnerable programs to verify its conclusions, which resulted in govulncheck reporting them as being vulnerable to the reported CVE.

Execution of govulncheck is part of our CI, so it'll block progress if one is found. Output for an example run can be found here.

Kindly requesting the smallstep team to please update the badger DB version so that these high severity vulnerabilities can be completely removed.

Please let me know if there are any challenges involved in this process, any reason this was not updated to maintain backward compatibility etc. If there’s no problem, by when can we expect a new release which fixes this.

The older Badger versions are kept around for backwards compatibility reasons, indeed. We have users using the old database formats, which depend on the older package versions. Based on our analysis and its conclusion from above, we don't see the need to patch the affected versions of the Badger DB or upgrade the supported versions.

In case you need a way to get your scanner(s) to not report on this vulnerability, then you could build the program while providing the nobadger build tag (e.g. go build -tags nobadger). It will fully exclude the Badger DB support, and thus also the code path that was reported as leading to certificates being vulnerable.

[hrithiky-777]

Hi Herman,

Thanks for quickly reaching back regarding this issue. Since govulncheck command doesn't raise this CVE and it's safe to say it's not reachable from the code. It's most likely a false positive on our side, so I'll close this issue.