One is the Loneliest Number: Crashing Rust's RSA Crate

In the realm of cryptography, we obsess over large numbers. We want our primes to be massive, un-factorable giants that would take the heat death of the universe to reverse-engineer. But in our quest for bigness, we often forget to check the basement. What happens when the numbers are too small? Specifically, what happens when a prime factor is the multiplicative identity: the number 1?

The rsa crate is the de facto standard for pure-Rust RSA implementations. It is memory-safe, fast, and generally robust. However, even the safest languages allow you to shoot yourself in the foot if you ignore the laws of mathematics. RSA relies on the premise that $n = p \times q$, where $p$ and $q$ are distinct primes. If $p=1$, the math doesn't just get weak; it breaks fundamental assumptions of the algorithm.

This vulnerability isn't a complex buffer overflow or a heap grooming masterpiece. It's a failure to ask a simple question: "Is this number actually big enough to be a prime?" The answer, for versions prior to 0.9.10, was a resounding "meh, close enough."

The vulnerability lies within src/key.rs, specifically in RsaPrivateKey::from_components. When constructing a private key from raw components (modulus, public exponent, private exponent, and primes), the library performs a sanity check to ensure the inputs are valid. Or at least, it tries to.

Here is the logic that was supposed to protect us:

// The offending code
for prime in &self.primes {
    if *prime < BigUint::one() { 
        // This only catches 0, not 1
        return Err(Error::InvalidPrime);
    }
    m *= prime;
}

Do you see it? The code checks if the prime is strictly less than one. In integer arithmetic, the only non-negative integer strictly less than 1 is 0. If an attacker passes 1, the check 1 < 1 evaluates to false, and the loop continues happily, accepting 1 as a valid prime factor.

Why does this matter? Because RSA private key operations—specifically the Chinese Remainder Theorem (CRT) optimizations—rely on calculating values modulo $(p-1)$. If $p=1$, then $(p-1)=0$. You don't need a PhD in math to know that modulo zero is a one-way ticket to Panic City.

The fix, applied in commit 2926c91bef7cb14a7ccd42220a698cf4b1b692f7, is almost embarrassingly simple. It transforms a loose check into a strict boundary.

The Vulnerable Logic:

if *prime < BigUint::one() {
    return Err(Error::InvalidPrime);
}

The Fixed Logic:

if *prime <= BigUint::one() {
    return Err(Error::InvalidPrime);
}

By adding that single equals sign (=), the developers ensured that 1 is rejected. Additionally, the patch included an upgrade to the underlying num-bigint-dig library (from 0.8.4 to 0.8.6), which hardened the BigInt arithmetic against internal panics. This two-pronged approach fixed the logic error at the gate and reinforced the walls against the crash.

To exploit this, we don't need a debugger or a shellcode encoder. We just need a text editor or a simple script to modify a serialized key. The most prominent target for this exploit is the PGP ecosystem, specifically applications using the pgp crate (which depends on rsa).

The Attack Chain:

1. Craft the Packet: The attacker generates a standard OpenPGP Secret Key packet. These packets contain the RSA private key components.
2. The Modification: The attacker locates the bytes corresponding to prime1 (p) or prime2 (q) and overwrites them to represent the integer 1.
3. Delivery: The attacker uploads this "poisoned" key to a keyserver, sends it via email to an automated gateway, or simply serves it to a client application.
4. The Crash: When the victim application parses the packet, it calls RsaPrivateKey::from_components. The validation passes (because $1 \not< 1$). The application then attempts to use the key. As soon as it attempts to calculate CRT parameters (like $dP = d \pmod{p-1}$), the BigUint library attempts a division by zero.

In Rust, a division by zero in the main thread (or an uncaught thread) results in a panic!. The process terminates immediately. For a web server or a key processing daemon, this is a total service outage.

You might look at the CVSS score of 2.7 (assigned by some CNAs) and think, "Low severity? I'll patch it next month." Do not be deceived. That score assumes a generic context where the attacker has no path to the vulnerability. In the real world, cryptographic libraries parse untrusted data by design.

If you are running an OpenPGP keyserver, an email encryption gateway, or an identity provider that accepts user-uploaded certificates, this is a Critical vulnerability. A single malicious packet can take down your entire ingestion pipeline. Since Rust panics unwind the stack, unless you have extremely robust panic catching at the worker level (which many async runtimes do, but not all logic paths guarantee), your service goes dark.

It is a trivial, asymmetric attack: low effort for the attacker, high availability impact for the defender. It turns your robust Rust application into a fragile house of cards.

The remediation is straightforward, thanks to Rust's package management. You need to ensure your dependency tree is using a safe version of the rsa crate.

Immediate Action: Run the following in your project root:

cargo update -p rsa

Verify that Cargo.lock shows rsa version 0.9.10 or higher.

For Downstream Users: If you use rPGP or other high-level wrappers, check their advisories. Most have already bumped their dependency versions. If you are pinning dependencies (bad practice, but it happens), unpin them to allow the patch to flow through.

> [!NOTE] > If you cannot upgrade immediately, you must implement manual validation of all RSA components before passing them to the rsa crate. Ensure p > 1 and q > 1.