Just a few quick notes/updates to correct some potentially inaccurate statements that are floating around on Reddit/Twitter etc:
- The bug only impacts Java 15 and above. The original advisory from Oracle incorrectly listed earlier versions (like 7, 8 and 11) as being impacted. They have since corrected this. Note that they now only list 17 and 18, because 15 and 16 are no longer supported.
- Bouncy Castle is not impacted by this vulnerability. They have their own ECDSA implementation, and it performs the relevant check to prevent this bug.
- Although an all-zero signature value is the simplest way to exploit this, there are several alternative values that exhibit the same bug. As previously mentioned, Project Wycheproof has an excellent selection of test vectors for this bug and many variations on it, in different signature formats, and for different elliptic curves.
- On a related note, some JWT libraries were initially assumed to be unaffected because a quirk of re-encoding raw (IEEE P1363) format signatures into ASN.1 format rejected zero values. But, as pointed out above, there are other invalid values that are not rejected by this conversion that still trigger the bug. Either upgrade your JVM, or your JWT library, and ideally both.
- Some JWT libraries also apparently accept signature values in several alternative encodings, so if you are checking for bad signatures in a pre-processing step then you have even more values to check. Again, best to update to get the patches rather than trying to fix this yourself.
One thought on “A few clarifications about CVE-2022-21449”
Thanks for these clarifications! Related to ASN.1(r,s) format it seems that 3006020100020100 easily triggers vulnerability at Oracle Java SE 17.0.2+, but Exception is dropped if full length ASN.1(r,s) is set such as 3044022000..00022000..00 And if ASN.1(r,s) works, I assume a malformed certificate could also be created (under e.g. “Microsoft ECC Product Root Certificate Authority 2018” in the Windows certificate store). And even an SSL/TLS man-in-the-middle could work in case vulnerable Java client is used…
Comments are closed.