Andrew Bennett

The pure-Erlang AES-GCM fallback in `jose jwa aes` derives the number of verified authentication tag bits from the attacker-supplied tag. In the `{aes gcm, Bits}` clause of the `block decrypt/4` function, the incoming tag is guarded only by `is binary/1` without a length check. Subsequently, the `gcm block decrypt/6` function computes `TBits = bit size(T)` and compares only those bits against the actual 128-bit tag. An attacker controlling a JWE token can truncate the authentication tag to as little as 8 bits, reducing forgery resistance from 2^-128 to 2^-8. This allows a forged ciphertext to be accepted as authentic within 256 attempts without the key, resulting in an authentication tag forgery and integrity bypass. Additionally, providing a tag longer than 128 bits causes a `badmatch` that crashes the decryption process. This issue occurs when AES-GCM is not provided by a native crypto NIF (Native Implemented Function), such as in FIPS, stripped, or older OTP builds.

The `jose jwa pkcs1` module contains a Bleichenbacher padding oracle in its pure-Erlang RSAES-PKCS1-v1 5 decryption. The function `eme pkcs1 decode/2` returns the recovered message for valid PKCS#1 v1.5 padding but returns a distinct error otherwise. Additionally, `rsaes pkcs1 decrypt/2` returns `{error, {badsize, }}` upon length check failure. The implementation lacks implicit-rejection countermeasures, failing to substitute a deterministic pseudo-random plaintext during padding failures, which leaks a padding-conformance signal. Furthermore, the use of non-blinded `crypto:mod pow/3` in the `dp/2` function allows the padding check to be distinguishable via timing attacks, even if error values are normalized. An unauthenticated attacker with the public RSA key can submit ciphertexts to a decryption endpoint that unwraps RSA1 5 JWE keys or calls `decrypt private/3` with `rsa pkcs1 padding` to recover plaintext, such as content-encryption keys, or forge signatures using adaptive chosen-ciphertext queries. This issue is only triggered when the `crypto fallback` option is enabled and the OTP runtime lacks native RSA1 5 decryption.

An improper handling of highly compressed data, known as data amplification, allows a remote attacker to exhaust a node's memory using a small crafted JWE token. The `jose jwe zip:uncompress/2` function in `src/jwe/jose jwe zip.erl` decompresses DEFLATE-compressed plaintext of a JWE containing the `zip: DEF` header by calling `zlib:inflate/2` on the attacker-controlled stream without bounds on output size or inflation ratio. This can cause a few-kilobyte token to inflate into hundreds of megabytes or gigabytes. Decompression occurs automatically during decryption via `jose jwe:block decrypt/2` (or `JOSE.JWE.block decrypt/2` in Elixir) before the payload is inspected. Using asymmetric key-management algorithms like RSA-OAEP or ECDH-ES, an attacker only needs the recipient's public key to craft the token, requiring no authentication. This can crash the BEAM and cause a denial of service.

The `jose jwk:shared secret/2` function (exposed in Elixir as `JOSE.JWK.shared secret/2`) is used to derive an ECDH shared secret from two JSON Web Keys (JWKs). A flaw exists where the function only matches when both JWKs have the same key type (`kty`) module. If the key types differ, such as an EC key and an RSA key, the fallback clause re-invokes the function with identical arguments, creating an unbounded tail-recursive loop. This loop consumes 100% of an Erlang scheduler's CPU. An attacker providing a specially crafted JWK can trigger this behavior, and repeated requests can exhaust all available schedulers, leading to a denial of service.

The library uses a password hash with insufficient computational effort when exporting password-encrypted private keys. Specifically, the `jose jwk:to der/2` (`JOSE.JWK.to der/2`) function utilizes the `jose jwk der:to binary/3` function to serialize keys as PKCS#8 EncryptedPrivateKeyInfo using the PBES2 scheme. This process employs hardcoded key-derivation parameters: PBKDF2-HMAC-SHA256 with 2048 iterations and an 8-byte random salt, both of which are significantly lower than industry standards. This weakness allows an attacker who obtains an exported encrypted blob to perform an offline dictionary or brute-force attack to recover the private key.

A timing side channel in the pure-Erlang Curve25519 fallback allows the recovery of a long-term X25519 private key. The implementation uses a recursive Montgomery ladder in the `jose jwa x25519:curve25519/2` function, where operations such as `jose jwa x25519:montgomery add/3` and `jose jwa x25519:montgomery double/1` rely on value-dependent Erlang bignum arithmetic. Consequently, the execution time of public entry points including `jose jwa x25519:scalarmult/2`, `jose jwa x25519:x25519/2`, `jose jwa x25519:x25519 base/1`, and `jose jwa x25519:sk to pk/1` varies based on the private key. This is exploitable when a service decrypts attacker-supplied ECDH-ES (JWE) messages via `JOSE.JWK.box decrypt ecdh es/2`, which calls `jose jwa curve25519:x25519 shared secret/2`. An attacker measuring decryption timing can recover the private key bit by bit, compromising data confidentiality and authenticity.

Inefficient algorithmic complexity allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key (JWK). When an application parses an untrusted JWK through the `jose jwk:from binary/1` or `jose jwk:from map/1` API (or the Elixir wrappers `JOSE.JWK.from binary/1` and `JOSE.JWK.from map/1`), an RSA private key providing `d`, `e`, and `n` but omitting Chinese Remainder Theorem parameters (`p`, `q`, `dp`, `dq`, `qi`) is processed by `convert sfm to crt/1`. This function attempts to recover missing primes by factoring the modulus, which is read from base64url input without validation. If the modulus cannot be split into two factors, the `convert sfm to crt find p/6` search loop performs continuous modular exponentiation, consuming significant CPU resources. Flooding the system with such requests can saturate all schedulers and deny service.

The library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. During verification, the function `jose jwk kty ec:verify/4` in `src/jwk/jose jwk kty ec.erl` splits the raw signature based on its actual byte length using `split binary(Signature, byte size(Signature) div 2)` instead of enforcing the fixed length required by RFC 7518 §3.4. The halves are then decoded using `crypto:bytes to integer/1`, which ignores leading zero bytes. This leads to signature malleability, where an attacker with a valid token can prepend leading zero bytes to the R and S halves to create multiple distinct signature byte strings that verify against the same key. While this does not allow for payload forgery or signer impersonation, it bypasses security controls that rely on signature uniqueness, such as token-revocation-by-hash, deduplication logic, or replay and idempotency caches.