Should we remove the rsa crate in surrealdb_jsonwebtoken and use another crate instead?

[fu050409]

My dependabot reported RUSTSEC-2023-0071 because of the unsafety in rsa crate, and I revealed that there's no rsa dependency found in the Cargo.lock generated by cargo generate-lockfile at the lastest version of JsonWebToken.

Is rsa crate necessary for us? Or can we use a more recent version?

Forgive me if this is due to my misunderstanding or stupidity :)

[gguillemas]

Hi @fu050409! Thank you for looking into the security of SurrealDB, we appreciate it!

You raise a good question. We have also looked into addressing this finding as our own Dependabot reported it as well.

The reason surrealdb-jsonwebtoken exists is to remove the ring dependency which is not compatible with the WebAssembly build of SurrealDB. There is an open PR in the original jsonwebtoken repository (Keats/jsonwebtoken#318) that will remove the dependency. This change will allow us to switch to the upstream code that no longer uses the rsa crate, finally resolving the issue. Since progress on that PR appears to be stalled, we considered backporting the changes that lead to the removal of the rsa dependency to surrealdb-jsonwebtoken.

However, looking into the original report, it appears that this issue occurs due to the fact that the encrypt and decrypt functions implemented in rsa were not constant-time and hence sensitive to timing side-channel attacks when decrypting a chosen plain-text, which could lead to an oracle resulting in broken confidentiality. In the case of SurrealDB (or jsonwebtoken for that matter) these functions are not used, since we only rely on rsa to perform signing and verification, none of which are reported to be affected by the Marvin Attack. Even if the timing issue affected the sign and verify operations as well, this attack does not seem applicable either, as it requires the attacker to be able to provide a known input (i.e. a chosen plain-text) to the vulnerable function. Since the sign and verify functions only take the digest (i.e. hash) of the JWT as its input, it would not be possible to perform the attack, as the value of the digest cannot be sufficiently controlled by the attacker. This is somewhat confirmed in this related comment from the original reporter in the original issue.

You may have noticed that the official page for the Marvin Attack explicitly mentions JSON Web Tokens being potentially affected. This does not seem to be the case according to the details released about the attack and how JWT signing and verification is done using the RS family of algorithms relying on PKCS#1 v1.5. There is a very comprehensive answer addressing this in the Cryptography StackExchange.

I hope this answer was helpful to you and others who may be seeing the same issue. We still hope to address this soon, either by moving to the upstream version of jsonwebtoken or by backporting their changes in order to upgrade to a more recent version.

Thank you again for taking the time to ask this question!

PS: I am not a cryptography expert, so take my conclusions with a grain of salt!