JVM Vulnerabiliity CVE-2022-21449
prashil-g opened this issue · 6 comments
used https://github.com/jfrog/jfrog-CVE-2022-21449 to check for our microservice and found that jjwt-0.9.1 might be vulnerable. Can you please confirm which version should we upgrade to if available for this CVE?
In build/libs/.jar/BOOT-INF/lib/jjwt-0.9.1.jar/io/jsonwebtoken/SignatureAlgorithm.class: potential use of ECDSA - may be vulnerable
I can confirm that jjwt 0.11.2 is vulnerable.
This JWT will pass all checks:
eyJhbGciOiJFUzI1NiJ9.eyJzdWIiOiJCb2IifQ.MAYCAQACAQA
JJWT is not vulnerable - the JVM itself is vulnerable, and only if you are running Java SE versions 15-15.0.6, 17-17.0.2, or 18.
If you are running one of these JVM versions, the 'correct' fix is to upgrade to Java versions 15.0.7, 17.0.3 or 18.0.1 respectively, immediately - you don't need to change JJWT versions at all. This is because even if you upgrade JJWT, anything else that uses ECDSA signatures (your own application code, other 3rd party libraries) would still be vulnerable. That is, upgrading JJWT doesn't fix the root cause of the problem - the root cause is in the JVM.
If you are not running on one of those above mentioned vulnerable JVM versions, you are not affected.
Now - all of that being said, we are in the process of releasing JJWT 0.11.3 that does provide additional security guards to address CVE-2022-21449, even on vulnerable JVMs. But again, this is essentially a feature enhancement - it only makes things nicer for JJWT, and doesn't address the root cause of the problem if it exists anywhere else in your code or libraries.
Well. you are correct, the problem is in JVM, not in this library. What i wanted to say is that it is possible to exploit this vulnerability with this library. POr example i could not exploit it with oauth jwt library.
@dhd0004 That may be true, but it's a false sense of safety - just because it doesn't surface through one library doesn't mean it is solved in all places - it may exist in another library or within application code or in a web server or the networking stack, etc.
Regardless of the upcoming 0.11.3 release, everyone who uses those JVM versions are vulnerable until they upgrade the JVM. It's simply not good enough to assume an app is safe just by upgrading just a JWT library. TLS negotiation (for example) could be vulnerable as well (among other things).
The other benefit of upgrading the JVM instead of any library is that you just don't have to change your application code - no changing project files, pulling in new dependencies, rebuild and re-release your software, etc. You can just swap out the JVM and you're safe against this particular vulnerability.
This is so much easier for most application teams than trying to track down any code where this problem might exist and then individually upgrading each one and cutting a new release, etc.
Resolved by the 0.11.3 release. Please allow 30 minutes or so for it to appear in Maven Central.