-
Notifications
You must be signed in to change notification settings - Fork 996
Stable release for CVE-2020-26160 fix #463
Comments
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 |
@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? |
same issue #422 |
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. |
agree |
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? |
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. |
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. |
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. |
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. |
I have fundamental question about this
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
}
}
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 Only way to have critical bug is to set if password == "mysecret" || password == "" {
login()
} Is it library fault when user codes one part of token validation to be optional? NB: to Fundamental question - it is really critical bug? |
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
|
why not just fix 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 |
We have just released a |
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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?
The text was updated successfully, but these errors were encountered: