cve-2020-26160 vulnerability in dgrijalva/jwt-go

[grandria]

There is a CVE (cve-2020-26160) detected in the library dgrijalva/jwt-go used by one of required library that you use (present in the go.sum file).

warning from github:

CVE-2020-26160
high severity
Vulnerable versions: <= 3.2.0
Patched version: No fix

jwt-go allows attackers to bypass intended access restrictions in situations with []string{} for m["aud"] (which is allowed by the specification). Because the type assertion fails, "" is the value of aud. This is a security problem if the JWT token is presented to a service that lacks its own audience check. There is no patch available and users of jwt-go are advised to migrate to golang-jwt at version 3.2.1

[yorinasub17]

I ran go mod why github.com/dgrijalva/jwt-go and it looks like this is coming from Azure:

%~> go mod why github.com/dgrijalva/jwt-go
# github.com/dgrijalva/jwt-go
github.com/gruntwork-io/terratest/modules/azure
github.com/Azure/go-autorest/autorest
github.com/Azure/go-autorest/autorest/adal
github.com/dgrijalva/jwt-go

@HadwaAbdelhalem do you think we can bump the Azure dependencies in terratest to latest version? Do you know if this is addressed in the newer versions of the SDK?

[HadwaAbdelhalem]

Hi @yorinasub17 investigating it now

[yorinasub17]

Some dependencies have been updated to remove reliance on this, but others still need to be updated.

[yorinasub17]

Ok I went through the dependency graph using go mod why, and this dependency is actually deeply nested across multiple packages, not just azure-sdk-go. It's also pulled in by various test packages in fairly modern versions.

I think we made a best effort attempt between #1008 and #1009 to avoid this reporting, but I don't see how it is practically feasible to avoid this.

FWIW, I don't see this as a huge issue given that:

• terratest is a testing library, and is entirely client side usage of this package.
• The vulnerability is really about server side verification of JWT tokens, not the client side.
• Furthermore, the vulnerability reported is for bypassing intended access restriction, something that is not really relevant to the use case of terratest (there is no access control in terratest library: that's all handled by the cloud services).

Going to close this as something we won't address directly. Happy to reconsider reopening if someone can comment on the relevance of the vulnerability in relation to terratest as a testing library.

[stevengonsalvez]

Just reopening this since that whole project is archived now : dgrijalva/jwt-go#462