Skip to content
This repository has been archived by the owner on May 21, 2022. It is now read-only.

Stable release for CVE-2020-26160 fix #463

Open
agiammar opened this issue Apr 12, 2021 · 15 comments
Open

Stable release for CVE-2020-26160 fix #463

agiammar opened this issue Apr 12, 2021 · 15 comments

Comments

@agiammar
Copy link

The CVE-2020-26160 vulnerability is fixed in the preview v4.0.0-preview1
Are there any plans to make the fix part of a stable release, either V4 or V3?

@agiammar agiammar changed the title Stable release CVE-2020-26160 fix Stable release for CVE-2020-26160 fix Apr 13, 2021
@ewilde
Copy link

ewilde commented Apr 19, 2021

We are maintaining a fixed version of this library https://github.com/form3tech-oss/jwt-go 

CVE fixed: https://github.com/form3tech-oss/jwt-go/releases/tag/v3.2.1

If that is of interest

@JohnStarich
Copy link

@dgrijalva Would you be open to cherry-picking the CVE fix from v4 onto a patch release of v3 – at least until repo ownership and v4 are sorted out?

@SVilgelm
Copy link

same issue #422

@JohnStarich
Copy link

JohnStarich commented Apr 21, 2021

I disagree about it being the same. Certainly is related though, thanks for the link!

This issue is not about how to fix the problem; it’s about getting the existing fix from v4 out to users in a stable release. I think ideally in v3, given that the new version is still in preview.

@SVilgelm
Copy link

agree

@petherin
Copy link

We issue tokens using v3, so all our tokens have aud as string not []string. If we upgrade to v4 to get the vulnerability fix, then aud will be []string in generated tokens and all our services consuming those tokens will break. To track down and make them all expect aud as []string is a difficult maintenance job with potentially disastrous authentication issues.

Can a future release be backwards-compatible so generated tokens have an aud of string or []string, maybe a flag that allows the user of the library to choose?

@tomqwpl
Copy link

tomqwpl commented Apr 27, 2021

Yes, we also have the same problem. A naive swap to the form3tech-oss version of this library causes JWT tokens generated by dex not to verify as the Audience field has changed to a []string and so the JWT token doesn't parse using StandardClaims.

@tomqwpl
Copy link

tomqwpl commented Apr 27, 2021

As I understand it, and looking at the code, the CVE only affects MapClaims, and not StandardClaims. If you use a StandardClaims and the token has an audience array rather than a string, parsing the JWT just fails, so you don't get into the situation described by the CVE.
The spec allows for aud to be a string or an array. StandardClaims originally chose to map this as a single string. It would therefore fail to parse a JWT if used with a token that had an array of aud values. Fine. Now, that situation has been reversed and that now (both 4.0 here and the form3tech-oss version) use an array for Audience in StandardClaims which means that it now only works for tokens that contain an array claim for audience. That's got nothing to do with the CVE, both are valid, so the change is unnecessary (and annoying) from the point of view of simply fixing CVE. The CVE only affects you if you're using MapClaims.

@SVilgelm
Copy link

@tommyo you are not correct, the aud in v4 support both, string and []string:

func (c *ClaimStrings) UnmarshalJSON(data []byte) error {

The go representation uses []string, but the json can be either just a string or []string.

@tomqwpl
Copy link

tomqwpl commented Apr 27, 2021

Ah, that makes sense. I hadn't spotted that, well I hadn't looked for it to be honest. I did wonder whether it might though, to avoid the incompatibility.
So it's just the form3tech-oss version that suffers from the issue. For our use, we don't use MapClaims, so as far as I can tell aren't affected by the CVE anyway. It would be nice to have a stable release of this repository with the fix in though, as it avoids having to add a CVE ignore line to loads of repositories, or adding replace lines to the go mod files in a bunch of repositories.

@petherin
Copy link

petherin commented Apr 28, 2021

In the scenario where we have several services using dgrijalva/jwt-go, we would like to upgrade dgrijalva/jwt-go in one of them to v4 (which would start sending out tokens where its StandardClaims.aud is []string) but still have the other services using dgrijalva/jwt-go v.3.2.0 continue to successfully consume those tokens. At the moment they would break if StandardClaims.aud is []string.

So in v4 it would be useful to decide whether using StandardClaims generates tokens whose aud is either []string or a string, to accommodate this overlap of some services having v4 and others v3.

@aldas
Copy link

aldas commented Jun 4, 2021

I have fundamental question about this critical bug.

jwt-go before 4.0.0-preview1 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.

Aud checking code is

func (m MapClaims) VerifyAudience(cmp string, req bool) bool {
	aud, _ := m["aud"].(string)
	return verifyAud(aud, cmp, req)
}

func verifyAud(aud string, cmp string, required bool) bool {
	if aud == "" {
		return !required
	}
	if subtle.ConstantTimeCompare([]byte(aud), []byte(cmp)) != 0 {
		return true
	} else {
		return false
	}
}

VerifyAudience is not called anywhere in library code. This is totally up to developer to implement.

Now examples:

func TestVerifyAud(t *testing.T) {
	var testCases = []struct {
		name  string
		token string
	}{
		{
			name:  "aud is missing",
			token: `{}`,
		},
		{
			name:  "aud is array",
			token: `{"aud": ["site"]}`,
		},
	}

	for _, tc := range testCases {
		t.Run(tc.name, func(t *testing.T) {
			var claims jwt.MapClaims
			if err := json.Unmarshal([]byte(tc.token), &claims); err != nil { // <-- aud is missing
				t.Fatal(err)
			}

			// If I set VerifyAudience to OPTIONAL why should it not PASS?
			optionalAudResult := claims.VerifyAudience("mysite.com", false) // <--- require set to false causes check to pass when aud is empty
			if !optionalAudResult {
				t.Fatalf("we have empty aud and set our verify check to optional but result was false - meaning verify had INCORRECT result")
			}

			requiredlAudResult := claims.VerifyAudience("mysite.com", true) // <--- require set to true
			if requiredlAudResult {
				t.Fatalf("we have empty aud and set our verify check to REQUIRED but result was true - meaning verify had INCORRECT result")
			}
		})
	}
}

If VerifyAudience second argument is to to true - meaning aud value is REQUIRED then it will never give us true when aud is array or empty in token.

Only way to have critical bug is to set VerifyAudience to OPTIONAL. But why on earth would you set this check to optional. This would be same as writing

if password == "mysecret" || password == "" {
  login()
}

Is it library fault when user codes one part of token validation to be optional?

NB: to fake empty aud values you need to have token signed with valid key - if attacker has valid key why they would need to manipulate aud values? If you are crossusing token singing keys for different sites and have set aud check optional - is not it more like your problem?

Fundamental question - it is really critical bug?

@aldas
Copy link

aldas commented Jun 4, 2021

just poiting out that you can not even marshal array to jwt.StandardClaim struct

func TestStandardClaims_VerifyAud(t *testing.T) {
	var testCases = []struct {
		name  string
		token string
	}{
		{
			name:  "aud is missing",
			token: `{}`,
		},
		{
			name:  "aud is array",
			token: `{"aud": ["site"]}`,
		},
	}

	for _, tc := range testCases {
		t.Run(tc.name, func(t *testing.T) {
			var claims jwt.StandardClaims
			if err := json.Unmarshal([]byte(tc.token), &claims); err != nil { // <-- aud is missing
				t.Fatal(err)
			}

			// If I set VerifyAudience to OPTIONAL why should it not PASS?
			optionalAudResult := claims.VerifyAudience("mysite.com", false) // <--- require set to false causes check to pass when aud is empty
			if !optionalAudResult {
				t.Fatalf("we have empty aud and set our verify check to optional but result was false - meaning verify had INCORRECT result")
			}

			requiredlAudResult := claims.VerifyAudience("mysite.com", true) // <--- require set to true
			if requiredlAudResult {
				t.Fatalf("we have empty aud and set our verify check to REQUIRED but result was true - meaning verify had INCORRECT result")
			}
		})
	}
}

it will fail with

 main_test.go:100: json: cannot unmarshal array into Go struct field StandardClaims.aud of type string

@aldas
Copy link

aldas commented Jun 4, 2021

why not just fix MapClaims.VerifyAudience with something like that if optional case is problematic

func (m MapClaims) VerifyAudience(cmp string, req bool) bool {
	rawAud, exists := m["aud"]
	if !exists {
		return !req
	}

	switch aud := rawAud.(type) {
	case string:
		return verifyAud(aud, cmp, req)
	case []string:
		for _, a := range aud {
			if verifyAud(a, cmp, req) {
				return true
			}
		}
		return !req && len(aud) == 0 // optional and empty is OK (verified)
	default: // not supported types are always incorrect
		return false
	}
}

and release v3.2.1 patch version. not need to have breaking changes at least if MapClaims is concerned.

@dgrijalva ?

@oxisto
Copy link

oxisto commented Jun 9, 2021

We have just released a v3.2.1 version of our forked/cloned community maintained version at https://github.com/golang-jwt/jwt/releases/tag/v3.2.1

jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 22, 2021
CVE-2020-26160[0] is an access restriction bypass under certain
circumstances when validating audience checks. The original
dgrijalva/jwt-go project is no longer maintained[1] and will not be
issuing a fix for this CVE[2]. Instead, they have transferred ownership
to golang-jwt/jwt[2][3][4].

The following was performed:

1. update chronograf and jsonweb to import golang-jwt/jwt
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. make
6. make test

References:
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26160
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 22, 2021
CVE-2020-26160[0] is an access restriction bypass under certain
circumstances when validating audience checks. The original
dgrijalva/jwt-go project is no longer maintained[1] and will not be
issuing a fix for this CVE[2]. Instead, they have transferred ownership
to golang-jwt/jwt[2][3][4].

The following was performed:

1. update chronograf and jsonweb to import golang-jwt/jwt
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. make
6. make test

References:
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26160
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 22, 2021
The dgrijalva/jwt-go project is no longer maintained[1] and they have
transferred ownership to golang-jwt/jwt[2][3][4].

The following was performed:

1. update services/httpd/handler*.go to import golang-jwt/jwt
2. revert testcase string comparison changes from 225bcec (back to v3)
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. go clean ./... && go build ./...
6. go test ./...

References:
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 22, 2021
The dgrijalva/jwt-go project is no longer maintained[1] and they have
transferred ownership to golang-jwt/jwt[2][3][4]. We should move to the
supported golang-jwt/jwt.

The following was performed:

1. update services/httpd/handler*.go to import golang-jwt/jwt
2. revert testcase string comparison changes from 225bcec (back to v3)
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. go clean ./... && go build ./...
6. go test ./...

References:
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
[5] influxdata#21926
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 22, 2021
The dgrijalva/jwt-go project is no longer maintained[1] and they have
transferred ownership to golang-jwt/jwt[2][3][4]. We should move to the
supported golang-jwt/jwt.

The following was performed:

1. update services/httpd/handler*.go to import golang-jwt/jwt
2. revert testcase string comparison changes from 225bcec (back to v3)
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. go clean ./... && go build ./...
6. go test ./...

References:
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
[5] influxdata#21926
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 22, 2021
The dgrijalva/jwt-go project is no longer maintained[1] and they have
transferred ownership to golang-jwt/jwt[2][3][4]. We should move to the
supported golang-jwt/jwt.

The following was performed:

1. update services/httpd/handler*.go to import golang-jwt/jwt
2. revert testcase string comparison changes from 225bcec (back to v3)
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. go clean ./... && go build ./...
6. go test ./...

References:
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
[5] influxdata#21926
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 23, 2021
The dgrijalva/jwt-go project is no longer maintained[1] and they have
transferred ownership to golang-jwt/jwt[2][3][4]. We should move to the
supported golang-jwt/jwt.

The following was performed:

1. update services/httpd/handler*.go to import golang-jwt/jwt
2. revert testcase string comparison changes from 225bcec (back to v3)
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy  # see note
5. go clean ./... && go build ./...
6. go test ./...

Note: 'go mod tidy' had unrelated changes (perhaps it wasn't run in
recent commits) so I removed the unrelated delta to keep this PR focused
on the dgrijalva/jwt-go to golang-jwt/jwt changes.

References:
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
[5] influxdata#21926
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 23, 2021
The dgrijalva/jwt-go project is no longer maintained[1] and they have
transferred ownership to golang-jwt/jwt[2][3][4]. We should move to the
supported golang-jwt/jwt.

The following was performed:

1. update services/httpd/handler*.go to import golang-jwt/jwt
2. revert testcase string comparison changes from 225bcec (back to v3)
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy  # see note
5. go clean ./... && go build ./...
6. go test ./...

Note: 'go mod tidy' had unrelated changes (perhaps it wasn't run in
recent commits) so I removed the unrelated delta to keep this PR focused
on the dgrijalva/jwt-go to golang-jwt/jwt changes.

References:
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
[5] influxdata#21926
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 23, 2021
The dgrijalva/jwt-go project is no longer maintained[1] and they have
transferred ownership to golang-jwt/jwt[2][3][4]. We should move to the
supported golang-jwt/jwt.

The following was performed:

1. update services/httpd/handler*.go to import golang-jwt/jwt
2. revert testcase string comparison changes from 225bcec (back to v3)
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy  # see note
5. go clean ./... && go build ./...
6. go test ./...

Note: 'go mod tidy' had unrelated changes (perhaps it wasn't run in
recent commits) so I removed the unrelated delta to keep this PR focused
on the dgrijalva/jwt-go to golang-jwt/jwt changes.

References:
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
[5] influxdata#21927
jdstrand added a commit to influxdata/influxdb that referenced this issue Jul 23, 2021
The dgrijalva/jwt-go project is no longer maintained[1] and they have
transferred ownership to golang-jwt/jwt[2][3][4]. We should move to the
supported golang-jwt/jwt.

The following was performed:

1. update services/httpd/handler*.go to import golang-jwt/jwt
2. revert testcase string comparison changes from 225bcec (back to v3)
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy  # see note
5. go clean ./... && go build ./...
6. go test ./...

Note: 'go mod tidy' had unrelated changes (perhaps it wasn't run in
recent commits) so I removed the unrelated delta to keep this PR focused
on the dgrijalva/jwt-go to golang-jwt/jwt changes.

References:
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
[5] #21926
jdstrand added a commit to influxdata/influxdb that referenced this issue Jul 23, 2021
The dgrijalva/jwt-go project is no longer maintained[1] and they have
transferred ownership to golang-jwt/jwt[2][3][4]. We should move to the
supported golang-jwt/jwt.

The following was performed:

1. update services/httpd/handler*.go to import golang-jwt/jwt
2. revert testcase string comparison changes from 225bcec (back to v3)
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy  # see note
5. go clean ./... && go build ./...
6. go test ./...

Note: 'go mod tidy' had unrelated changes (perhaps it wasn't run in
recent commits) so I removed the unrelated delta to keep this PR focused
on the dgrijalva/jwt-go to golang-jwt/jwt changes.

References:
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
[5] #21927
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 23, 2021
CVE-2020-26160[0] is an access restriction bypass under certain
circumstances when validating audience checks. The original
dgrijalva/jwt-go project is no longer maintained[1] and will not be
issuing a fix for this CVE[2]. Instead, they have transferred ownership
to golang-jwt/jwt[2][3][4].

The following was performed:

1. update chronograf and jsonweb to import golang-jwt/jwt
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. make
6. make test

References:
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26160
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 23, 2021
CVE-2020-26160[0] is an access restriction bypass under certain
circumstances when validating audience checks. The original
dgrijalva/jwt-go project is no longer maintained[1] and will not be
issuing a fix for this CVE[2]. Instead, they have transferred ownership
to golang-jwt/jwt[2][3][4].

The following was performed:

1. update chronograf and jsonweb to import golang-jwt/jwt
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. make
6. make test

References:
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26160
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 23, 2021
CVE-2020-26160[0] is an access restriction bypass under certain
circumstances when validating audience checks. The original
dgrijalva/jwt-go project is no longer maintained[1] and will not be
issuing a fix for this CVE[2]. Instead, they have transferred ownership
to golang-jwt/jwt[2][3][4].

The following was performed:

1. update chronograf and jsonweb to import golang-jwt/jwt
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. make
6. make test

References:
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26160
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
jdstrand added a commit to jdstrand/influxdb that referenced this issue Jul 23, 2021
CVE-2020-26160[0] is an access restriction bypass under certain
circumstances when validating audience checks. The original
dgrijalva/jwt-go project is no longer maintained[1] and will not be
issuing a fix for this CVE[2]. Instead, they have transferred ownership
to golang-jwt/jwt[2][3][4].

The following was performed:

1. update chronograf and jsonweb to import golang-jwt/jwt
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. make
6. make test

References:
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26160
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
jdstrand added a commit to influxdata/influxdb that referenced this issue Jul 23, 2021
CVE-2020-26160[0] is an access restriction bypass under certain
circumstances when validating audience checks. The original
dgrijalva/jwt-go project is no longer maintained[1] and will not be
issuing a fix for this CVE[2]. Instead, they have transferred ownership
to golang-jwt/jwt[2][3][4].

The following was performed:

1. update chronograf and jsonweb to import golang-jwt/jwt
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. make
6. make test

References:
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26160
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
jdstrand added a commit to influxdata/influxdb that referenced this issue Jul 23, 2021
* chore: upgrade to golang-jwt 3.2.1 to fix CVE-2020-26160

CVE-2020-26160[0] is an access restriction bypass under certain
circumstances when validating audience checks. The original
dgrijalva/jwt-go project is no longer maintained[1] and will not be
issuing a fix for this CVE[2]. Instead, they have transferred ownership
to golang-jwt/jwt[2][3][4].

The following was performed:

1. update chronograf and jsonweb to import golang-jwt/jwt
2. go mod edit -require github.com/golang-jwt/jwt@v3.2.1+incompatible
3. go mod edit -droprequire github.com/dgrijalva/jwt-go
4. go mod tidy
5. make
6. make test

References:
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26160
[1] dgrijalva/jwt-go#462
[2] dgrijalva/jwt-go#463
[3] https://github.com/dgrijalva/jwt-go/blob/master/README.md
[4] https://github.com/golang-jwt/jwt
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants