Closed thomas-fossati closed 1 year ago
I made #841 which fixes jws.Verify
, but I think jwe.Encrypt
may be susceptible to the same problem...
Yeah, I patched jwe.Encrypt as well. Please let me know if this fixes your problems
╰─± go run main.go
failed to verify JWS: could not verify message using any of the signatures or keys
Thanks @lestrrat for the super-quick patch!
Cool. I think you know the drill: I'll merge, but I'm putting off a release until I either get enough stuff or I feel comfortable that nothing else broke or is missing.
Thanks for the headsup!
The following is
ExampleJWX
from the README slightly modified to read an EC key whose x-coord has been moved out of the P-256 curve.go1.19
crypto/elliptic
reacts quite drastically when it finds out it's operating on invalid curve points (see release notes):"Operating on invalid curve points (those for which the IsOnCurve method returns false, and which are never returned by Unmarshal or by a Curve method operating on a valid point) has always been undefined behavior and can lead to key recovery attacks. If an invalid point is supplied to Marshal, MarshalCompressed, Add, Double, or ScalarMult, they will now panic."
In fact, compiling and running the snippet above with go1.19 panics like this:
Note that this same code compiled against 1.18 or earlier versions would just fail verification.
The trouble is this new behaviour makes it trivial to crash/DoS a verification service built on top of jwx.
BCP225 says:
"Some cryptographic operations [...] take inputs that may contain invalid values. This includes points not on the specified elliptic curve or other invalid points (e.g., [Valenta], Section 7.1). The JWS/JWE library itself must validate these inputs before using them, or it must use underlying cryptographic libraries that do so (or both!)."
so it'd seem right for jwx to do the input validation, at
jwk.ParseKey
,jwk.PublicKeyOf
orjwt.Parse
.