Stefan Eissing

Ao usar credenciais de usuário ambientes, uma solicitação HTTP direcionada a uma origem pode ser enviada por meio de uma conexão previamente autenticada via Negotiate para uma origem diferente, deixando as credenciais pretendidas da solicitação sem uso.

Quando compilado com wolfSSL, o curl pode validar incorretamente o hash de uma chave pública fixada (pinned) em relação a uma chave que o peer TLS não possui. Isso ocorre durante o handshake TLS, quando o wolfSSL valida a conexão, mas o curl reanalisa posteriormente o certificado. Um campo de comprimento de validade manipulado pode enganar o curl, fazendo com que ele extraia e corresponda a uma chave incorporada diferente, autorizando incorretamente a chave pública fixada.

Uma transferência `ftp://` configurada com `CURLUSESSL NONE` pode reutilizar uma conexão de controle FTP agrupada que foi previamente atualizada com `STARTTLS` e autenticada usando um certificado de cliente. Como o segundo identificador não realiza um novo handshake TLS nem um novo login FTP, o servidor continua a autorizá-lo sob a identidade do certificado do primeiro identificador.

A ativação de `CURLOPT CRLF` permite a injeção de comandos durante operações IMAP APPEND. Ao transmitir dados com expansão de final de linha, o curl anuncia a contagem de bytes de entrada brutos no literal `IMAP APPEND {N}`. Como o servidor lê apenas $N$ bytes para a carga útil, os bytes de estouro restantes são interpretados e executados como comandos IMAP pipelined dentro da sessão autenticada.

Existe um problema onde a chave de reutilização de conexão não inclui a vinculação quando o `CURLOPT INTERFACE` (ou a opção de linha de comando `--interface`) é configurado com prefixos como `if!`, `host!` ou `ifhost!`. Isso permite que uma transferência subsequente que solicite uma origem diferente reutilize silenciosamente uma conexão existente, resultando no tráfego originando-se do endereço de origem da transferência anterior.

A função de correspondência do cache de conexão não considera a opção de certificado de cliente automático. Isso permite que uma conexão Schannel em cache, já autenticada, seja reutilizada para uma transferência redirecionada para uma origem diferente, mesmo que a opção de certificado de cliente automático tenha sido explicitamente desativada para essa transferência específica para evitar tal situação.

Quando compilado com GnuTLS, um servidor WebSocket malicioso pode fazer com que o curl envie memória além do seu buffer de envio. Isso ocorre devido a uma leitura fora dos limites que acontece quando a função `gnutls record send()` retorna um número de bytes enviados superior ao número de bytes que lhe foi solicitado para enviar, geralmente após um envio bloqueado.

Ao usar um usuário ambiente em uma transferência inicial com autenticação Negotiate, o curl pode transmitir incorretamente detalhes de credenciais para uma segunda origem não relacionada ao ser instruído a seguir redirecionamentos.

Um proxy HTTP pode enganar o libcurl para que este envie as credenciais de origem, como senhas Basic ou tickets Negotiate/Kerberos, diretamente para o próprio proxy. Isso acontece quando o proxy responde a uma solicitação de túnel `CONNECT` com um status 401 `WWW-Authenticate:` em vez do status 407 `Proxy-Authenticate:` esperado.

Um problema de corrupção de memória do tipo use-after-free ocorre durante uploads HTTP/2. A falha acontece quando o curl manipula incorretamente uma resposta HTTP/2 `RST STREAM` recebida de um servidor com o motivo `HTTP 1 1 REQUIRED` ou `REFUSED STREAM`, levando ao uso após a liberação de um objeto `struct Curl easy`. Um invasor remoto que controle um servidor malicioso pode explorar isso para causar a falha do cliente ou, sob condições altamente específicas envolvendo conhecimento preciso da arquitetura do alvo, layout de memória e configuração TLS, executar código remotamente.

Ao utilizar o backend wolfSSL com o cache de CA habilitado, existe uma falha onde o callback `CURLOPT SSL CTX FUNCTION` pode ser sobrescrito. Se este callback substituir o armazenamento de confiança (trust store), o libcurl pode reinstalar silenciosamente o armazenamento em cache após o retorno do callback. Isso resulta em um cenário onde um certificado confiado pelo armazenamento em cache é aceito incorretamente, mesmo que tenha sido rejeitado pelo armazenamento selecionado via callback.

Existe uma falha onde o software reutiliza incorretamente a configuração de uma conexão HTTP para um hostname específico ao usar a autenticação Negotiate, especificamente quando a requisição inicial é feita com credenciais vazias. Este comportamento pode levar a uma situação em que a requisição de um usuário é transmitida através de uma conexão previamente autenticada por outro usuário.

Um erro lógico no mecanismo de pool de conexões permite que o software reutilize uma conexão incorreta para solicitações autenticadas via Negotiate. Isso ocorre mesmo quando as solicitações são configuradas para usar serviços diferentes, podendo levar a uma solicitação ser enviada por meio de uma conexão autenticada para um serviço diferente no mesmo servidor.

Existe um problema onde o libcurl pode enviar dados de requisição em uma nova conexão antes de aplicar a falha de verificação do certificado. Isso ocorre quando um usuário se conecta primeiramente a um servidor HTTP/3 legítimo e, posteriormente, se conecta a uma máquina impostora de um invasor que não possui um certificado válido. O vazamento de informações sensíveis pode acontecer se uma sessão SSL em cache for utilizada (onde `CURLOPT SSL SESSIONID CACHE` está habilitado) e os dados iniciais (early data) estiverem ativos (onde o bit `CURLSSLOPT EARLYDATA` está definido em `CURLOPT SSL OPTIONS`).

Quando configurado para usar um arquivo `.netrc` para credenciais e, ao mesmo tempo, especifica-se uma URL contendo um nome de usuário, mas sem senha (ex: `https://user@example.com/`), o software pode recuperar e usar incorretamente a senha de outro usuário definido no arquivo `.netrc` para aquele host, caso exista e não haja correspondência para o usuário especificado.

Existe uma falha onde uma nova transferência que utiliza STARTTLS para atualizar a conexão pode reutilizar incorretamente uma conexão ativa existente, apesar de haver uma incompatibilidade na configuração TLS.

O componente WebSocket da biblioteca libcurl contém um problema de alocação de recursos. Por padrão, o curl responde automaticamente aos frames PING do WebSocket. Como o software carece de um limite superior para a alocação de memória de frames não confirmados, um invasor remoto atuando como um servidor malicioso pode esgotar toda a memória disponível inundando o cliente com mensagens PING rápidas e sequenciais, resultando em uma negação de serviço.

Um problema na função de recebimento UDP do QUIC permite que um servidor HTTP/3 remoto malicioso cause a negação de serviço. A função auxiliar descarta datagramas UDP de comprimento zero antes de contabilizá-los no orçamento de pacotes por chamada, permitindo que um peer QUIC conectado envie datagramas vazios continuamente para travar o cliente indefinidamente.

Existe um problema no procedimento de autenticação de certificados onde a biblioteca mantém um pool de conexões para reutilização em transferências subsequentes. Se um handle utilizar inicialmente a confiança CA nativa padrão e for posteriormente alterado para material CA personalizado, ele poderá continuar a confiar no armazenamento da plataforma nativa para transferências subsequentes usando esse handle. Isso pode permitir que um invasor remoto realize a falsificação de dados ou obtenha acesso não autorizado a informações protegidas.

Um problema de use-after-free existe no libcurl relacionado ao gerenciamento da árvore de dependência de fluxo HTTP/2. Isso ocorre quando um aplicativo configura a árvore usando `CURLOPT STREAM DEPENDS` ou `CURLOPT STREAM DEPENDS E`, chama a função `curl easy reset()` e, em seguida, encerra o handle através da função `curl easy cleanup()`. Durante a limpeza final, a biblioteca tenta acessar e modificar uma estrutura interna que já havia sido liberada durante a operação de reset. Esta falha pode permitir que um invasor remoto cause a negação de serviço.