Dan Gudmundsson

A validação inadequada da quantidade especificada na entrada no stdlib permite que um invasor remoto degrade a disponibilidade ao fornecer uma URI cujo componente de porta seja uma sequência muito longa de dígitos. A função `uri string:get port/1` passa a substring da porta para `binary to integer/1` sem limite de comprimento. Consequentemente, uma porta sintaticamente válida de até aproximadamente 1,26 milhão de dígitos pode ser convertida com sucesso, consumindo centenas de milissegundos de aritmética de precisão arbitrária no processo solicitante. Essa conversão é alcançada por todos os caminhos de análise de autoridade em `uri string:parse/1`, incluindo as formas de host, nome registrado, IPv4 e IPv6. Qualquer aplicação que utilize `uri string:parse/1` para analisar URIs fornecidas por invasores está exposta.

A aplicação ssl não detecta ciclos ao reconstruir uma cadeia de certificados de pares incompleta durante um handshake TLS ou DTLS. Especificamente, a função `handle incomplete chain/5` passa a cadeia para `build certificate chain/5`, que então utiliza `do certificate chain/7` para percorrer relações de emissor sem limite de profundidade ou detecção de ciclos. Se um par fornecer dois certificados assinados mutuamente de forma desordenada, o sistema entra em recursão indefinida, fazendo com que a pilha de chamadas e o acumulador de cadeia cresçam sem limites. Um invasor remoto não autenticado pode explorar isso enviando uma cadeia de certificados manipulada em uma mensagem de handshake para esgotar a memória e travar o nó BEAM. Isso afeta tanto servidores quanto clientes e requer apenas uma conexão TCP e um handshake parcial.

A aplicação inadequada da integridade da mensagem durante a transmissão no módulo `tls gen connection` permite que um invasor posicionado na rede injete texto simples não autenticado que a aplicação cliente TLS posteriormente trata como dados de servidor autenticados. A função `handle protocol record()` não rejeita registros APPLICATION DATA que chegam em estados de pré-handshake quando o endpoint atua como um cliente. Um invasor pode enviar registros APPLICATION DATA em texto simples durante o handshake, que são armazenados em buffer e entregues à aplicação como dados autenticados pós-handshake assim que o handshake for concluído. Isso resulta na injeção cega de bytes não autenticados. A janela de injeção é maior para versões do TLS anteriores ao TLS 1.3 do que para o TLS 1.3.

A aplicação ssl não valida se a lista de identidade PSK e a lista de binder transportadas em uma extensão de pré-chave compartilhada ClientHello TLS 1.3 possuem o mesmo comprimento. Na função `handle pre shared key/3`, um registro `OfferedPreSharedKeys` com comprimentos incompatíveis é encaminhado para `use/4`, o que causa a falha do processo do manipulador de tickets de sessão. Um invasor remoto não autenticado pode enviar um ClientHello manipulado para um servidor TLS 1.3 com tickets de sessão habilitados para interromper o processamento de tickets de sessão. Embora novos handshakes TLS 1.3 possam ser concluídos, eles falham quando o servidor tenta emitir um ticket de sessão, tornando o TLS 1.3 inutilizável no listener até que a aplicação seja reiniciada. Conexões TLS 1.2 não são afetadas.

Uma condição de corrida de Time-of-check Time-of-use (TOCTOU) existe no módulo `dtls packet demux` dentro do componente ssl. Isso ocorre quando um listener de servidor DTLS usa um processo `gen server` `dtls packet demux` compartilhado para rotear datagramas UDP. Um invasor remoto não autenticado pode causar uma falha ao enviar rapidamente múltiplas mensagens ClientHello do mesmo endereço e porta de origem. Isso cria uma condição de corrida no armazenamento de chave-valor interno `gb trees`, resultando em um erro `{key exists, {old, Client}}` que encerra o processo demux. Como esse processo é compartilhado, todas as sessões DTLS ativas no listener são encerradas, levando a uma negação de serviço persistente. O problema está localizado no arquivo `lib/ssl/src/dtls packet demux.erl` e afeta apenas implantações que utilizam `ssl:listen/2` com transporte baseado em UDP.

O uso de uma chave criptográfica padrão no servidor DTLS permite o cálculo previsível de cookies DTLS durante a janela de inicialização, possibilitando a evasão da verificação de endereço de origem. Na inicialização do servidor, a função `dtls server connection:initial hello/3` inicializa a variável `previous cookie secret` como um binário vazio em vez de um valor aleatório. Como o HMAC com uma chave vazia é determinístico, um invasor que observe o ClientHello em texto simples pode calcular o `dtls handshake:cookie()` e forjar um cookie DTLS válido antes da primeira rotação do segredo (geralmente entre 0 a 15 segundos). Isso permite a amplificação de handshake DTLS com endereços de origem falsificados, ignorando a mitigação de negação de serviço destinada a evitar que IPs falsificados forcem o servidor a alocar estado e realizar operações criptográficas dispendiosas.

A validação inadequada de certificados nos módulos `pubkey cert` e `public key` permite a evasão de nameConstraints de DNS durante a verificação de nome de host TLS. Isso ocorre porque a função `pubkey cert:validate names/6` verifica apenas as entradas de DNS do Subject Alternative Name (SAN) em relação às nameConstraints, o que significa que certificados sem um SAN satisfazem trivialmente as restrições de DNS permitidas. Simultaneamente, a função `public key:pkix verify hostname/3` recorre ao CommonName do assunto quando nenhum SAN está presente, comparando-o com o nome de host de referência. Essa combinação permite que uma CA subordinada com nameConstraints de DNS restritas emita um certificado final que um cliente TLS OTP aceita para um nome de host fora de escopo. Essa evasão é acessível via `ssl:connect` utilizando `verify peer`, uma CA confiável, SNI e o correspondente de nome de host https estrito.