Xclow3N

Quando o `http.Transport` envia uma solicitação HTTP/1 CONNECT contendo um `Request.Body` não vazio, o corpo é gravado diretamente na conexão sem enquadramento após os cabeçalhos da solicitação. Se o servidor responder à solicitação CONNECT com uma resposta keep-alive não-2xx, a conexão é retornada ao pool de inatividade. Como as solicitações CONNECT não devem ter um corpo de solicitação, o servidor pode interpretar os bytes restantes do corpo como uma solicitação HTTP/1.1 pipelined subsequente na conexão. Isso resulta em uma conexão de pool dessincronizada, fazendo com que o próximo usuário dessa conexão leia a resposta da solicitação injetada. Em proxies reversos, como o `httputil.ReverseProxy`, que utilizam um `Transport` compartilhado, esse comportamento pode levar ao envenenamento de resposta entre usuários (cross-user response poisoning).

Um invasor remoto não autenticado pode causar a negação de serviço ao enviar uma operação LDAP completa seguida pelos bytes iniciais de uma LDAPMessage incompleta na mesma conexão. Essa sequência força o servidor a atribuir a conexão a um segundo thread de trabalho antes que o resultado do primeiro worker seja liberado. O segundo worker então bloqueia até que o `nsslapd-ioblocktimeout` seja atingido enquanto retém o mutex de conexão, o que impede a entrega do resultado da operação concluída. Ao repetir esse processo em um pequeno número de conexões proporcional ao tamanho do pool de threads de trabalho configurado, um invasor pode esgotar todo o pool sob as configurações padrão, negando o serviço a todos os clientes, incluindo usuários anônimos e autenticados via plaintext e TLS.

Existe uma falha onde o servidor não descarta bytes em texto simples armazenados em buffer de uma conexão de cliente durante a negociação StartTLS. Isso permite que um invasor on-path injete uma mensagem LDAP manipulada que é processada após a atualização do TLS. Devido a uma colisão de messageID, a resposta à mensagem injetada é entregue ao cliente em vez da resposta à operação pendente do próprio cliente. Consequentemente, um aplicativo cliente pode tratar incorretamente uma tentativa de autenticação (bind) falha como bem-sucedida.

Um cliente HTTP/2 não autenticado pode explorar a maneira como o proxy encaminha dados para upgrades HTTP não-WebSocket configurados antes que o upstream os aceite. Ao colocar uma requisição HTTP/1.1 completa em dados CONNECT estendidos, o invasor pode fazer com que o proxy degrade a requisição e escreva os dados sem moldura (unframed) para um upstream HTTP/1.1 com keep-alive. Isso resulta em uma resposta contrabandeada (smuggled response) que permanece na fila do pool compartilhado, podendo ser recebida por um cliente downstream diferente. Este problema não afeta upgrades de WebSocket, CONNECT simples, keep-alive de backend desativado, pools por downstream ou configurações onde `max requests per connection` está definido como 1.

Ocorre uma interpretação inconsistente de requisições HTTP, conhecida como HTTP Request/Response Smuggling, em rotas de serverless-plugin. Isso permite que um invasor manipule o fluxo de requisições para que outros clientes recebam respostas escolhidas pelo invasor ou respostas destinadas a outros usuários.

Usuários autenticados podem realizar server-side request forgery (SSRF) ao enviar URLs manipuladas. Este problema ocorre na função `fetch url()` da classe `ScenarioImport`, permitindo que atacantes façam requisições HTTP arbitrárias. Isso pode ser utilizado para sondar serviços de rede interna, enumerar portas através de assinaturas de erro e acessar endpoints de metadados de nuvem para recuperar credenciais sensíveis.

O software contém dois problemas de Server-Side Request Forgery (SSRF). SSRF é uma falha que permite que um invasor induza a aplicação do lado do servidor a fazer requisições para um local não pretendido, potencialmente acessando recursos internos ou ignorando restrições de rede.

Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks. Specifically, Netty terminates chunk header parsing at carriage return/newline characters within quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers. The root cause is that Netty does not validate that carriage return/line feed bytes are forbidden inside chunk extensions before the terminating carriage return/line feed. A request containing carriage return/line feed bytes within a chunk extension value should be rejected outright as invalid. This issue can lead to request smuggling, cache poisoning, access control bypass, and session hijacking.

Name of the Vulnerable Software and Affected Versions Apache Tomcat versões 11.0.0-M1 através de 11.0.18, 10.1.0-M1 através de 10.1.52, 9.0.0.M1 através de 9.0.115, 8.5.0 através de 8.5.100, e 7.0.0 através de 7.0.109 Description Uma interpretação inconsistente de requisições HTTP ('Smuggling de Requisição/Resposta HTTP') existe no Apache Tomcat devido a uma extensão de chunk inválida. Isso pode potencialmente permitir que um atacante contrabandeie requisições, levando a um comportamento inesperado ou violações de segurança. Recommendations Atualize para a versão 11.0.20 Atualize para a versão 10.1.52 Atualize para a versão 9.0.116

O analisador HTTP/1.1 processa incorretamente strings entre aspas em valores de extensão de codificação de transferência em blocos (chunked transfer encoding). Especificamente, o analisador encerra a análise do cabeçalho do bloco ao encontrar uma sequência de retorno de carro e alimentação de linha (CRLF) dentro de uma string entre aspas, em vez de tratar isso como um erro de análise. Esse comportamento permite que um invasor injete requisições HTTP contrabandeadas, o que pode levar ao envenenamento de cache, bypass de controle de acesso e sequestro de sessão.

A biblioteca go-mail manipula incorretamente os valores `mail.Address` quando passados aos comandos `MAIL FROM` ou `RCPT TO` do cliente SMTP. Isso pode levar ao roteamento incorreto de endereços ou ao contrabando de parâmetros ESMTP. A exploração bem-sucedida requer que o código do usuário permita a entrada de endereços de e-mail arbitrários. O problema origina-se do uso do valor bruto do `Address` em vez do método `String()`, que aplica escape e aspas corretamente nos endereços de e-mail. Especificamente, um endereço de e-mail forjado como `"toni.tester@example.com> ORCPT=admin@admin.com"@example.com` poderia ser mal interpretado pelo servidor SMTP, potencialmente roteando e-mails para destinatários não intencionais ou permitindo a injeção de comandos SMTP adicionais.