Bleichenbacher padding oracle in RSAES-PKCS1-v1_5 decryption in jose

The pure-Erlang RSAES-PKCS1-v1_5 decryption in the jose_jwa_pkcs1 module is a Bleichenbacher padding oracle. eme_pkcs1_decode/2 returns the recovered message when a decrypted block has valid PKCS#1 v1.5 padding (a leading 0x00 0x02, a padding string of at least eight non-zero bytes, and a 0x00 separator) and returns a distinct error result otherwise, and rsaes_pkcs1_decrypt/2 additionally returns {error, {badsize, _}} when the length check fails. The implementation applies no implicit-rejection countermeasure (RFC 8017 §7.2.2): it does not substitute a deterministic pseudo-random plaintext on a padding failure, so a one-bit padding-conformance signal leaks to the caller. Because the underlying modular exponentiation in dp/2 is a raw, non-blinded crypto:mod_pow/3, the padding check also stays distinguishable by timing even when an application normalizes every failure to a single error value.

An unauthenticated attacker who knows only the public RSA key and can submit ciphertexts to a decryption endpoint that unwraps RSA1_5 JWE keys (or otherwise calls decrypt_private/3 with rsa_pkcs1_padding) can use this oracle to recover the plaintext of intercepted ciphertexts, such as content-encryption keys and thus the protected message, or to forge signatures, through roughly 10^4 to 10^6 adaptive chosen-ciphertext queries.

This issue affects jose: from 1.3.0 before 1.11.13.

The vulnerable code path is only reached when jose performs RSAES-PKCS1-v1_5 decryption with its pure-Erlang fallback (the jose_jwa_pkcs1 module) instead of the native OTP public_key implementation. This requires the crypto_fallback option to be enabled (application:set_env(jose, crypto_fallback, true), or JOSE.crypto_fallback(true) in Elixir) and the OTP runtime not to provide native RSA1_5 decryption. When native OTP RSA support is selected, decryption does not go through jose_jwa_pkcs1.