Martin Karrer

A validação inadequada de certificados com incompatibilidade de host permite que um adversário no meio se passe por um peer TLS usando um certificado com um curinga de rótulo parcial. A função `try match wildcard/4` em `src/ssl verify hostname.erl` ancora apenas o texto antes e depois do asterisco em identificadores como `f*.example.net`, permitindo que o curinga consuma pontos e aceite certificados para domínios não autorizados, como `f.evil.example.net`. Isso contraria a RFC 6125, que restringe curingas ao rótulo mais à esquerda. Além disso, o correspondente permite que `*.168.1.1` corresponda ao literal de IP `192.168.1.1`. Este problema afeta clientes que desativam a Indicação do Nome do Servidor (SNI), servidores que verificam nomes de host de certificados de cliente e chamadores diretos da função `verify cert hostname/2`.

Existe um problema onde um servidor de redirecionamento pode obter credenciais de `basic auth` e `cookie` por meio de um redirecionamento no mesmo host para um esquema ou porta diferente. Quando `follow redirect` está habilitado, a função `hackney:follow redirect/10` em `src/hackney.erl` reemite solicitações para o destino `Location`. A verificação realizada por `hackney:maybe strip auth on redirect/3` compara apenas o nome do host das URLs atual e de redirecionamento. Consequentemente, um redirecionamento de `https` para `http` no mesmo host envia os cabeçalhos `Authorization` e `Cookie` em texto simples, permitindo que um invasor no caminho os intercepte. Da mesma forma, um redirecionamento para uma porta diferente no mesmo host envia essas credenciais para um serviço diferente. Isso ocorre via HTTP/1.1 e HTTP/2 quando `location trusted` não está configurado.

A validação inadequada de certificados em `hackney ssl` permite que um invasor no caminho (on-path) se passe por um servidor fixado a uma autoridade certificadora (CA) privada. Isso ocorre porque a função `hackney ssl:merge ssl opts/3` mantém um callback padrão `{partial chain, fun hackney ssl:partial chain/1}` mesmo quando o usuário substitui o armazenamento de confiança por `cacerts` ou `cacertfile` em `ssl options`. Como o OTP prioriza esse callback em relação ao armazenamento de confiança configurado, qualquer cadeia de certificados que termine em uma raiz publicamente confiável é aceita, ignorando a fixação da CA privada. O invasor deve possuir um certificado publicamente confiável para o nome do host fixado para ter sucesso.

Um problema de alocação de recursos em `hackney conn` permite que um servidor HTTP malicioso esgote a memória do cliente ao enviar um corpo de resposta excessivamente grande ou altamente compactado. As funções `hackney:request/5` e `hackney:body/1` retornam o corpo completo da resposta sem limites sobre o quanto o processo de conexão armazena em buffer. Especificamente, `hackney conn:read full body/2` e os acumuladores HTTP/2 e HTTP/3 anexam cada fragmento até que o corpo termine. Quando a opção `{auto decompress, true}` é utilizada, o corpo armazenado em buffer é inflado em uma única etapa usando `zlib:gunzip/1` ou `zlib:inflate/2`, que retornam toda a saída de uma vez. Isso pode levar a uma amplificação significativa de memória; por exemplo, um corpo gzip de 1 MB pode inflar para 1 GB.