Rossabaker

**Nome do software vulnerável e versões afetadas** Versões 0.21.26 e anteriores do http4s Versões 0.22.0 a 0.22.2 do http4s Versões 0.23.0 e 0.23.1 do http4s Versões 1.0.0-M1 a 1.0.0-M24 do http4s **Descrição** A configuração padrão do CORS no http4s é vulnerável a um ataque de reflexão de origem e a um ataque de origem nula. Isso permite que um script malicioso exfiltre informações confidenciais utilizando as credenciais do usuário. O problema está relacionado ao fato de o sinalizador `anyOrigin` em `CORSConfig` estar definido como `true` por padrão, o que permite o compartilhamento de recursos independentemente da configuração `allowedOrigins`. Além disso, a configuração `allowCredentials` estar definida como `true` por padrão permite o compartilhamento de respostas que possam exigir credenciais para informações confidenciais com qualquer origem. **Recomendações** Para as versões 0.21.26 e anteriores, atualize para a versão 0.21.27 ou posterior. Para as versões 0.22.0 a 0.22.2, atualize para a versão 0.22.3 ou posterior. Para as versões 0.23.0 e 0.23.1, atualize para a versão 0.23.2 ou posterior. Para as versões 1.0.0-M1 a 1.0.0-M24, atualize para a versão 1.0.0-M25 ou posterior. Como solução alternativa temporária, considere definir `anyOrigin` como `false` e incluir especificamente origens confiáveis em `allowedOrigins`, ou desativar credenciais definindo `allowCredentials` como `false`.

**Nome do software vulnerável e versões afetadas** Versões do http4s de 0.21.7 a 0.21.23 Versões do http4s de 0.22.0-M1 a 0.22.0-M8 Versão 0.23.0-M1 do http4s Versões 1.0.0-M1 a 1.0.0-M22 do http4s **Descrição** A função `StaticFile.fromUrl` pode revelar a presença de um diretório em um servidor quando o esquema `URL` não é `file://` e a URL aponta para um recurso acessível sob seu esquema e autoridade. A função retorna `F[None]`, indicando ausência de recurso, se `url.getFile` for um diretório, sem primeiro verificar o esquema ou a autoridade da URL. Se uma conexão de URL com o esquema e a URL retornasse um fluxo, e o caminho na URL existisse como um diretório no servidor, a presença do diretório no servidor poderia ser inferida a partir da resposta 404. O conteúdo e outros metadados sobre o diretório não são expostos. **Recomendações** Para as versões 0.21.7 a 0.21.23, atualize para a versão v0.21.24. Para as versões 0.22.0-M1 a 0.22.0-M8, atualize para a versão v0.22.0-RC1. Para a versão 0.23.0-M1, atualize para a versão v0.23.0-RC1. Para as versões 1.0.0-M1 a 1.0.0-M22, atualize para a versão v1.0.0-M23. Como solução alternativa temporária, evite chamar `StaticFile.fromUrl` com URLs que não sejam de arquivos.

**Nome do software vulnerável e versões afetadas: versões do blaze-core anteriores à 0.14.15 versões do http4s-blaze-server anteriores à 0.21.17 Descrição: O problema é causado pela aceitação ilimitada de conexões no blaze-core, levando ao esgotamento dos identificadores de arquivo. Isso pode agravar a degradação em serviços incapazes de lidar com a carga atual de solicitações, já que as conexões recebidas continuam sendo aceitas e adicionadas a uma fila ilimitada. Cada conexão aloca um identificador de soquete, o que esgota um recurso escasso do sistema operacional. Isso também pode confundir os circuit breakers de nível superior, que funcionam com base na detecção de conexões com falha. A grande maioria dos usuários afetados está utilizando o software como parte do http4s-blaze-server. O http4s fornece um mecanismo para limitar conexões abertas, mas ele é aplicado dentro do loop de aceitação do Blaze, após a conexão ser aceita e o soquete aberto. Recomendações: Para versões do blaze-core anteriores à 0.14.15, atualize para a versão 0.14.15 ou posterior, que inclui um parâmetro `maxConnections` para limitar conexões simultâneas. Para versões do http4s-blaze-server anteriores à 0.21.17, considere usar um side-car do Nginx como proxy reverso para aplicar a semântica de limitação de conexões antes que os sockets cheguem ao blaze-core, ou use servidores alternativos, como http4s-ember-server, http4s-jetty ou http4s-tomcat. Como solução temporária, considere definir um número negativo para o parâmetro `maxConnections` para executar sem limites, mas isso não é recomendado.

**Nome do software vulnerável e versões afetadas: Versões do http4s anteriores à 0.21.17 Versões do http4s anteriores à 0.22.0-M2 Versões do http4s anteriores à 1.0.0-M14 Descrição: O problema está relacionado à biblioteca blaze-core, que aceita conexões sem limite em seu pool de seletores. Isso pode levar a uma negação de serviço, já que as conexões recebidas continuam sendo aceitas e adicionadas a uma fila ilimitada, esgotando os escassos recursos do sistema operacional. O mecanismo de middleware `MaxActiveRequests` no http4s limita apenas o número de conexões que podem ser processadas simultaneamente, não o número de conexões que podem permanecer abertas. O número estimado de dispositivos potencialmente afetados em todo o mundo não está disponível. Não há informações sobre incidentes reais em que essa vulnerabilidade tenha sido explorada. Detalhes técnicos sobre a exploração incluem o fato de que cada conexão aloca um identificador de soquete, o que pode confundir disjuntores de circuito de nível superior que funcionam com base na detecção de conexões com falha. Recomendações: Para versões anteriores à 0.21.17, considere usar um side-car do Nginx como proxy reverso para aplicar semântica de limitação de conexão antes que os soquetes cheguem ao blaze-core. Para versões anteriores à 0.22.0-M2, considere usar um side-car do Nginx como proxy reverso para aplicar semântica de limitação de conexão antes que os sockets cheguem ao blaze-core. Para versões anteriores à 1.0.0-M14, considere usar um side-car do Nginx como proxy reverso para aplicar semântica de limitação de conexão antes que os sockets cheguem ao blaze-core. Como alternativa, considere usar o http4s-e