Add advisories for libcrux-psq, libcrux-ecdh & libcrux-ed25519

[jschneider-bensch]

This PR adds advisories for the libcrux crates libcrux-psq, libcrux-ecdh and libcrux-ed25519. Our security policy for libcrux is now such that we publish GitHub security advisories for every release that contains bug fixes. We would like to make those visible to users of cargo audit and cargo deny as well.

The relevant GHSA for this batch of releases is GHSA-435g-fcv3-8j26.

[djc]

Okay, sorry, one more request: can you use a short description of the actual issue as the title of the advisory, rather than "Bug-Fix in "?

In the future, would be nice to also have one commit per advisory, but it's okay to leave it for now.

[jschneider-bensch]

Okay, sorry, one more request: can you use a short description of the actual issue as the title of the advisory, rather than "Bug-Fix in "?

Yes, I'll change the titles.

In the future, would be nice to also have one commit per advisory, but it's okay to leave it for now.

Ah, sorry! I can squash after review, no problem.

[djc]

Also now that there's one advisory per issue, might be nice to set url to the upstream issue (or PR).

[nadimkobeissi]

Advisories for some of these bugs were already proposed in #2647. These advisories are fine too, but there are still some issues that are not addressed:

First, the advisories do not include any impact or mitigation sections explaining what an attacker can achieve by exploiting these vulnerabilities, making it difficult for downstream consumers to assess their risk.

For example, the malformed AES-GCM ciphertext causing DoS in libcrux-psq is simply described as:

propagate AEADError instead of panicking

Users don't get any chance to truly understand how these bugs impact them.

As I've stated to @djc on the rust-lang Zulip, I've been in the security industry for 15 years, and my understanding is that the standard for advisories is that they should discuss impact and mitigation, not that users should go and play detective and read commits and PRs to figure out how they're impacted. Furthermore, I think most if not all RustSec advisories that already exist follow the standard industry practice of writing down impact and mitigation.

Second, these advisories are incomplete and do not cover all of my findings, most notably the critical nonce reuse vulnerability in Cryspen's hpke-rs package, for which a RustSec advisory was already proposed here — I guess you'll file a separate PR for that one?

Finally, there are additional findings relating to ML-DSA, discussed in this blog post, for which no RustSec advisory has been proposed yet. There are also additional unfixed bugs in Cryspen's formal specifications/verification targets, but I think those fall outside the scope of any RustSec advisory (I could be wrong).

Editing to add one more note: these advisories credit me for the bugs I've found but not for my fixes. My pull requests proposing fixes for these advisories on the Cryspen GitHub were closed and I was blocked for posting them, then, @franziskuskiefer, Cryspen's CEO, copy-pasted my fixes from the PRs he closed without giving me credit. I'd appreciate credit for the copy-pasted fixes as well as for disclosing the vulnerabilities. Thanks.

[jschneider-bensch]

I've changed the titles now to describe the issues that were fixed.

If you think it's better now, I can squash, so there will be one commit per advisory.

[djc]

If you think it's better now, I can squash, so there will be one commit per advisory.

It's a start at least.

Let's get these merged and move from there.

Would be great if you can squash to one commit per advisory. (I recommend git-absorb if you don't know it yet.)

[nadimkobeissi]

I'm really glad to see that the issues were finally merged with a descriptive headline and an actual CVSS. Both of these things didn't exist until an hour ago.

Hopefully we can just get the hpke-rs issues merged and we can finally move on.

[nadimkobeissi]

@jschneider-bensch Your CVSS in the RustSec advisory contradicts the severity rating in GHSA-435g-fcv3-8j26.

• GHSA-435g-fcv3-8j26 lists the severity rating as moderate.
• However, you gave the AES-GCM DoS issue a CVSS 4.0 classification of CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N, which translates to 8.2/10, which is High.

In addition, that classification is not completely accurate. Since this is a library, a more accurate classification would have been CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H. This would have translated to a CVSS4.0 rating of 8.9/10, which is still High.

Note that that GHSA also includes additional vulnerabilities, I'm just citing one here.

I'm rejecting credit for the GHSA until the severity rating is amended to be accurate.