Andrew Bennett

O fallback AES-GCM em pure-Erlang no `jose jwa aes` deriva o número de bits da tag de autenticação verificados a partir da própria tag fornecida pelo atacante. Na cláusula `{aes gcm, Bits}` da função `block decrypt/4`, a tag de entrada é protegida apenas por `is binary/1`, sem verificação de comprimento. A verificação na função `gcm block decrypt/6` então calcula `TBits = bit size(T)` e compara apenas esses bits com a tag real de 128 bits. Um atacante que controle um token JWE pode truncar a tag de autenticação para apenas 8 bits, reduzindo a resistência a falsificações de 2^-128 para 2^-8. Isso permite que um texto cifrado forjado seja aceito como autêntico em até 256 tentativas sem o conhecimento da chave, resultando em uma falsificação de tag de autenticação e bypass de integridade. Além disso, fornecer uma tag com mais de 128 bits causa um `badmatch` que interrompe o processo de descriptografia. Este problema ocorre quando o AES-GCM não é fornecido por um NIF (Native Implemented Function) de criptografia nativa, como em builds FIPS, stripped ou versões antigas do OTP.

O módulo `jose jwa pkcs1` contém um oráculo de preenchimento Bleichenbacher em sua descriptografia RSAES-PKCS1-v1 5 em pure-Erlang. A função `eme pkcs1 decode/2` retorna a mensagem recuperada para preenchimentos PKCS#1 v1.5 válidos, mas retorna um erro distinto caso contrário. Além disso, `rsaes pkcs1 decrypt/2` retorna `{error, {badsize, }}` quando a verificação de comprimento falha. A implementação não aplica contra-medidas de rejeição implícita, não substituindo um texto simples pseudo-aleatório determinístico em falhas de preenchimento, o que vaza um sinal de conformidade de preenchimento. Além disso, o uso de `crypto:mod pow/3` não cegado na função `dp/2` permite que a verificação de preenchimento seja distinguível via ataques de tempo, mesmo que os valores de erro sejam normalizados. Um invasor não autenticado com a chave RSA pública pode enviar textos cifrados para um endpoint de descriptografia que desempacota chaves JWE RSA1 5 ou chama `decrypt private/3` com `rsa pkcs1 padding` para recuperar o texto simples, como chaves de criptografia de conteúdo, ou forjar assinaturas usando consultas adaptativas de texto cifrado escolhido. Este problema ocorre apenas quando a opção `crypto fallback` está habilitada e o runtime OTP não fornece descriptografia RSA1 5 nativa.

Um tratamento inadequado de dados altamente compactados, conhecido como amplificação de dados, permite que um invasor remoto esgote a memória de um nó usando um token JWE pequeno e manipulado. A função `jose jwe zip:uncompress/2` em `src/jwe/jose jwe zip.erl` descompacta o texto simples compactado via DEFLATE de um JWE que contém o cabeçalho `zip: DEF`, chamando `zlib:inflate/2` no fluxo controlado pelo invasor, sem limites para o tamanho da saída ou a taxa de inflação. Isso pode fazer com que um token de alguns kilobytes se transforme em centenas de megabytes ou gigabytes. A descompactação ocorre automaticamente durante a descriptografia via `jose jwe:block decrypt/2` (ou `JOSE.JWE.block decrypt/2` em Elixir) antes que a carga útil seja inspecionada. Usando algoritmos de gerenciamento de chaves assimétricas como RSA-OAEP ou ECDH-ES, um invasor precisa apenas da chave pública do destinatário para criar o token, sem necessidade de autenticação. Isso pode travar o BEAM e causar a negação de serviço.

A função `jose jwk:shared secret/2` (exposta em Elixir como `JOSE.JWK.shared secret/2`) é utilizada para derivar um segredo compartilhado ECDH a partir de duas JSON Web Keys (JWKs). Existe uma falha onde a função apenas corresponde quando ambas as JWKs possuem o mesmo módulo de tipo de chave (`kty`). Se os tipos de chave diferirem, como uma chave EC e uma chave RSA, a cláusula de fallback reinvoca a função com argumentos idênticos, criando um loop recursivo de cauda ilimitado. Este loop consome 100% da CPU de um escalonador Erlang. Um invasor que forneça uma JWK especialmente manipulada pode desencadear esse comportamento, e solicitações repetidas podem esgotar todos os escalonadores disponíveis, resultando em uma negação de serviço.

A biblioteca utiliza um hash de senha com esforço computacional insuficiente ao exportar chaves privadas criptografadas por senha. Especificamente, a função `jose jwk:to der/2` (`JOSE.JWK.to der/2`) utiliza a função `jose jwk der:to binary/3` para serializar chaves como PKCS#8 EncryptedPrivateKeyInfo usando o esquema PBES2. Este processo emprega parâmetros de derivação de chave fixos: PBKDF2-HMAC-SHA256 com 2048 iterações e um salt aleatório de 8 bytes, ambos significativamente inferiores aos padrões da indústria. Essa fraqueza permite que um invasor que obtenha um blob criptografado exportado realize um ataque de dicionário offline ou de força bruta para recuperar a chave privada.

Um canal lateral de temporização no fallback Curve25519 em pure-Erlang permite a recuperação de uma chave privada X25519 de longo prazo. A implementação utiliza uma escada de Montgomery recursiva na função `jose jwa x25519:curve25519/2`, onde operações como `jose jwa x25519:montgomery add/3` e `jose jwa x25519:montgomery double/1` dependem de aritmética de bignum do Erlang dependente de valor. Consequentemente, o tempo de execução dos pontos de entrada públicos, incluindo `jose jwa x25519:scalarmult/2`, `jose jwa x25519:x25519/2`, `jose jwa x25519:x25519 base/1` e `jose jwa x25519:sk to pk/1`, varia com base na chave privada. Isso é explorável quando um serviço descriptografa mensagens ECDH-ES (JWE) fornecidas por um invasor via `JOSE.JWK.box decrypt ecdh es/2`, que chama `jose jwa curve25519:x25519 shared secret/2`. Um invasor que meça o tempo de descriptografia pode recuperar a chave privada bit a bit, comprometendo a confidencialidade e a autenticidade dos dados.

A complexidade algorítmica ineficiente permite que um invasor remoto não autenticado cause uma negação de serviço por exaustão de CPU ao enviar uma Chave Web JSON (JWK) RSA manipulada. Quando uma aplicação analisa uma JWK não confiável através da API `jose jwk:from binary/1` ou `jose jwk:from map/1` (ou os wrappers Elixir `JOSE.JWK.from binary/1` e `JOSE.JWK.from map/1`), uma chave privada RSA que fornece `d`, `e` e `n`, mas omite os parâmetros do Teorema do Resto Chinês (`p`, `q`, `dp`, `dq`, `qi`), é processada por `convert sfm to crt/1`. Esta função tenta recuperar os primos ausentes fatorando o módulo, que é lido da entrada base64url sem validação. Se o módulo não puder ser dividido em dois fatores, o loop de busca `convert sfm to crt find p/6` realiza exponenciação modular contínua, consumindo recursos significativos de CPU. O envio massivo de tais solicitações pode saturar todos os escalonadores e negar o serviço.

A biblioteca aceita assinaturas JWS ECDSA (ES256, ES256K, ES384 e ES512) de comprimento não canônico. Durante a verificação, a função `jose jwk kty ec:verify/4` em `src/jwk/jose jwk kty ec.erl` divide a assinatura bruta com base em seu comprimento de byte real usando `split binary(Signature, byte size(Signature) div 2)` em vez de impor o comprimento fixo exigido pela RFC 7518 §3.4. As metades são então decodificadas usando `crypto:bytes to integer/1`, que ignora bytes zero iniciais. Isso leva à maleabilidade da assinatura, onde um invasor com um token válido pode prefixar bytes zero iniciais às metades R e S para criar múltiplas strings de bytes de assinatura distintas que são verificadas com a mesma chave. Embora isso não permita a falsificação de carga útil ou a personificação de um signatário, isso anula controles de segurança que dependem da unicidade da assinatura, como revogação de token por hash, lógica de deduplicação ou caches de replay e idempotência.