#1057096 rust-rsa: CVE-2023-49092: RUSTSEC-2023-0071: Marvin Attack: potential key recovery through timing sidechannels

Package:
src:rust-rsa
Source:
src:rust-rsa
Submitter:
Salvatore Bonaccorso
Date:
2026-01-12 17:39:11 UTC
Severity:
normal
Tags:
#1057096#5
Date:
2023-11-29 16:27:15 UTC
From:
To:
Hi,

The following vulnerability was published for rust-rsa.

CVE-2023-49092[0]:
| RustCrypto/RSA is a portable RSA implementation in pure Rust. Due to
| a non-constant-time implementation, information about the private
| key is leaked through timing information which is observable over
| the network. An attacker may be able to use that information to
| recover the key. There is currently no fix available. As a
| workaround, avoid using the RSA crate in settings where attackers
| are able to observe timing information, e.g. local use on a non-
| compromised computer.

TTBOMK no fix is yet available at time of writing.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-49092
https://www.cve.org/CVERecord?id=CVE-2023-49092
[1] https://github.com/RustCrypto/RSA/security/advisories/GHSA-c38w-74pg-36hr
[2] https://github.com/RustCrypto/RSA/issues/19#issuecomment-1822995643
[3] https://rustsec.org/advisories/RUSTSEC-2023-0071.html
[4] https://people.redhat.com/~hkario/marvin/

Regards,
Salvatore

#1057096#12
Date:
2024-10-26 06:05:22 UTC
From:
To:
Control: affects 1057096 + rsopv

My understanding is that we have other instances of the MARVIN attack
available in debian which have not yet been solved.  Those other
instances are *not* marked with an RC-critical severity.

For example, #1065683 is timing leakage for RSA decryption with
libgcrypt, and #1068418 is timing leakage for RSA decryption with
rust-openssl.  Both are severity: important, but 1057096 is severity:
grave, which is keeping rust-rsa from migrating to testing.

I would also like to see sidechannel-resistant RSA more widely
available, but i'm not sure what we gain from having the severity of
this bug elevated beyond the severity of the other issues.  In practice,
this is also keeping the non-affected parts of rust-rsa from being able
to migrate.

For example, this severity means that rsopv (a Rust implementation of
the signature-verification-only subset of the Stateless OpenPGP CLI)
cannot migrate into testing. (i've marked this bug as Affects: rsopv to
make this clear).  rsopv doesn't even implement RSA decryption.

Salvatore, would you object to setting the severity of this bug from
"grave" to "important", in line with the other MARVIN-related bug
reports?

#1057096#19
Date:
2024-10-26 07:12:47 UTC
From:
To:
Hi Daniel,

Thanks for asking. I can explain. Yes the other are not at RC level,
the reason behind this was, the package is new and was not yet in a
stable release, so aim to have it without the issue in trixie or not
in trixie.

I will not object if you plan to lower the severity, but it would have
been nice to not introduce the package in trixie release once stable
with the issue.

Regards,
Salvatore

#1057096#24
Date:
2024-10-27 16:29:13 UTC
From:
To:
Hi Salvatore--
 […]

I understand this reasoning, and i sympathize.  But the side effect
seems to be that other, unaffected benficial uses of RSA (e.g. signature
verification) are blocked from entering Trixie, while Trixie remains
shipping similarly risky code from other toolkits.  (and by "similarly
risky" i mean "problematic in a programmatic, automated setting where an
oracle has access to ~microsecond timing information during decryption").

I agree, and i will continue pushing on rust-rsa upstream to adopt
constant-time code.  Maybe they can even land it in time for trixie,
which would be great!

But i'm reducing the severity from grave to important (in parity with
other codebases with the same problem) so that trixie could have the
benefit code making use of other (non-vulnerable) aspects of RSA.

Thanks for talking this over, and for all the work you do to keep Debian
in good health.  If you (or anyone on the security team) end up changing
your mind and decide that this is the wrong decision, and you want to
set the severity back to grave, i won't object.

All the best,