Reject out-of-range RSA-PSS signature representatives
Review baseline: 75aee5b (v0.6.1).
Finding
rust/core/src/sig.rs:472-474 verifies PSS through RsaPublicKey::verify(Pss, ...). The selected dynamic-digest verification path in pinned rsa 0.9.10 (src/pss.rs:126-140) checks the signature byte length but does not reject a signature integer greater than or equal to the modulus before modular exponentiation. The same dependency's typed digest verifier does include that check.
The package therefore accepts some invalid, noncanonical signatures. Given a published valid signature representative s, adding the public modulus n can produce a different representative that still fits the required signature byte length. The current verifier accepts both, contrary to RFC 8017 section 5.2.2's representative-range check and section 8.1.2's verification procedure.
This is signature malleability and incorrect verification, not evidence that an attacker can sign an arbitrary new message or recover a private key. It affects the shared Rust core, so both the guest provider and native Rust host use the defective path.
Reproduction
Using conformance/vectors/rsa_pss_2048_sha256_mgf1_32_test.json, tcId 1:
- Import the published SPKI with SHA-256 and salt length 32.
- Verify its published message and signature: success.
- Add the public modulus to the signature integer and encode it as the same 256-byte length.
- Verify the same message with the modified signature: the current core also returns success; it must return
authentication-failed.
A standalone probe linked against the checkout's compiled core reproduces this. No new secret material is needed; all inputs derive from the vendored public verification vector.
Requested resolution
Enforce the RSA signature representative range before the selected verification path, or use a backend entry point that enforces it. Add cross-implementation conformance coverage for an out-of-range same-width signature, not only malformed byte lengths and padding.
Reference: https://www.rfc-editor.org/rfc/rfc8017.html#section-5.2.2
Reject out-of-range RSA-PSS signature representatives
Review baseline: 75aee5b (v0.6.1).
Finding
rust/core/src/sig.rs:472-474verifies PSS throughRsaPublicKey::verify(Pss, ...). The selected dynamic-digest verification path in pinnedrsa0.9.10 (src/pss.rs:126-140) checks the signature byte length but does not reject a signature integer greater than or equal to the modulus before modular exponentiation. The same dependency's typed digest verifier does include that check.The package therefore accepts some invalid, noncanonical signatures. Given a published valid signature representative s, adding the public modulus n can produce a different representative that still fits the required signature byte length. The current verifier accepts both, contrary to RFC 8017 section 5.2.2's representative-range check and section 8.1.2's verification procedure.
This is signature malleability and incorrect verification, not evidence that an attacker can sign an arbitrary new message or recover a private key. It affects the shared Rust core, so both the guest provider and native Rust host use the defective path.
Reproduction
Using
conformance/vectors/rsa_pss_2048_sha256_mgf1_32_test.json, tcId 1:authentication-failed.A standalone probe linked against the checkout's compiled core reproduces this. No new secret material is needed; all inputs derive from the vendored public verification vector.
Requested resolution
Enforce the RSA signature representative range before the selected verification path, or use a backend entry point that enforces it. Add cross-implementation conformance coverage for an out-of-range same-width signature, not only malformed byte lengths and padding.
Reference: https://www.rfc-editor.org/rfc/rfc8017.html#section-5.2.2