Closed P3ngu1nW closed 3 months ago
Hi @P3ngu1nW ,
i neither quite sure what fix you are looking for nor what 'set a maximum token size for expansion' means.
You can deregister compression via: https://github.com/dvsekhvalnov/jose-jwt?tab=readme-ov-file#deregister-algorithm-implementations or https://github.com/dvsekhvalnov/jose-jwt?tab=readme-ov-file#strict-validation
If you want to put max cap on incoming token length - it's beyond library responsibility and honestly quite easy to do before calling library.
Can probably limit memory decompression buffer size by default to some reasonable value. And make it configurable. What can be good default?
Maybe we can learn from Azure’s approach and set an upper limit of 250K.
https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/wiki/zipcve
yeah, i think doable. let's mark for next release.
@P3ngu1nW i've put fix for decompression thing: https://github.com/dvsekhvalnov/jose-jwt/pull/238 will be part of v5 release.
Also, i guess figured out what did mean by unit test:
string s = Jose.JWT.Decode(eviltoken, Key, JwsAlgorithm.RS256);
that line doesn't really protects you, right? I think there is a bug in strict validation, it doesn't apply signing check to encrypted tokens and vice versa. Will fix it too.
v5.0.0 released to nuget.org
https://github.com/dvsekhvalnov/jose-jwt/releases/tag/v5.0.0
Summary
Jose.JWT.Decode
will automatically detect whether the user inputs JWS or JWE. This means that if the attacker obtains the public key of JWS, he can forge a JWE Token to pass the verification.What's more, the attacker can use the "zip" claim to construct a DEFLATE Decompression bomb to crash or DOS a system.
Similar CVE: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/security/advisories/GHSA-8g9c-28fc-mcx2
POC
How to Fix
set a maximum token size for expansion.