jwtk/jjwt

CVE reported against 0.11.5

jimshowalter opened this issue · 5 comments

jimshowalter commented

OSV dev started reporting this yesterday:

io.jsonwebtoken:jjwt-impl:0.11.5:
        GHSA-r65j-6h5f-4f92
                severity: MODERATE
                summary: JJWT improperly generates signing keys
                CVEs:
                        https://nvd.nist.gov/vuln/detail/CVE-2024-31033

Any chance of a fix in 0.11.x? We are currently unable to upgrade to 0.12.x due to breaking changes.

lhazlewood commented

This is not a security issue, and I disagree with the reporter's assessment.

Why wasn't the JJWT team contacted before creating a CVE? Even if it was a security issue, which this one is not, that's irresponsible reporting, preventing a possible fix being released before public disclosure.

This is an invalid CVE report for a number of reasons:

  1. The JJWT version used in the reporter's test code is more than 6 years old, probably a 0.9.x release, and has been unsupported for many years. The same tests run against later/current JJWT versions fail.

  2. The methods reported are already @Deprecated and documented accordingly because many people do not understand how to use Base64 in security contexts, presumably the CVE reporter as well.

  3. Base64 text in these contexts is not a key. It is an encoding of a key.. If someone generates a random string to use as a key directly, as the reporter did in their report (instead of generating an actual key and then Base64-encoding it), they're fundamentally subverting the security model. It's not a library's fault that the library user a) purposefully breaks their own security model and b) completely ignores both the JavaDoc documentation and compiler warnings for the corresponding methods.

  4. The preferred/recommended/documented methods accept an actual Key object, and have been in JJWT for many versions, long before 0.12. Interestingly, the reporter could create a valid Key by Base64-decoding their invalid test string and using the resulting raw bytes to create a Key object, and it's still the same problem. If you're purposefully trying to subvert your own key inputs, there's nothing a library can do about it.

  5. EVEN if the generated string was malformed, it's Base64-decoded length in bits MUST be large enough for the associated signature algorithm, otherwise an exception is thrown by JJWT (a WeakKeyException), meaning the security model defined in the JWA RFC is still maintained.

  6. The reporter was manipulating the key on the JWT creation side, again meaning the error is with the creation/issuer. As long as the key bit length is valid (and will be enforced per above), the generated JWT still reflects the intended security strength per the JWA RFC specification. It is not possible for the JWT recipient or man-in-the-middle to maliciously manipulate the JWT, retaining the associated algorithm's security properties, and it is still verifiable by any recipient with the same bit-for-bit decoded key.

We even have an entire section in our documentation about Base64 in security contexts, which also the CVE reporter either ignored or failed to acknowledge.

As such the CVE is invalid and reflection of an invalid test due to lack of understanding of JJWT's API, it's clear documentation on recommended practices and deprecation, and the still validly-maintained security properties of the associated signature algorithm.

It feels very much a scenario of 'let me see if I can come up with a test case that breaks something I think is invalid without understanding how to use the library or read it's documentation or even historical GitHub issues'. A simple communication with the JJWT team or cursory search would have easily identified the invalid test.

  • 👍7
jimshowalter commented

There's some way to challenge CVEs, but I don't know what it is. Have seen some CVEs with rebuttals attached.

FWIW, I'm just letting you know about the CVE. Had nothing to do with it. Am not even qualified to evaluate it.

  • 👍1
lhazlewood commented

@jimshowalter thanks so much, I definitely appreciate it!

I'm assuming you're good to go on your respective projects then? Is there anything I can help answer for you regarding API usages?

jimshowalter commented

Yes, we're fine. We have a way to override.

There's some info here about disputing CVEs: h2database/h2database#3686

  • 👍1
lhazlewood commented

@jimshowalter just an update: the CVE reporter has agreed that this was an erroneously created CVE, and they've agreed to mark this CVE to REJECTED status (it is currently marked as DISPUTED). They've also deleted their test project that was previously located at https://github.com/2308652512/JJWT_BUG since it didn't reflect tests with any recently supported JJWT release. The Mitre team responsible for reviews should (to the best of my knowledge) change status to REJECTED relatively soon.

  • 👍8