Após a notícia de alguns dias atrás de que o Curl estava se preparando para sua pior falha de segurança em muito tempo que afeta o projeto, o Curl 8.4 já está disponível e com uma nova luz sobre esse assunto. Sendo assim, o novo Curl 8.4 tenta resolver uma grande falha de segurança.
Curl 8.4 foi lançado com esta correção de segurança de nível “alto”, outro problema de segurança “baixo” também foi resolvido e, em seguida, a correção de bugs e o recurso habituais funcionam para esta biblioteca de download amplamente usada e utilitário de linha de comando curl para baixar arquivos por meio de vários protocolos de rede.
Curl 8.4 tenta resolver uma grande falha de segurança
CVE-2023-38545 é o problema de segurança “alta” resolvido no CVE 8.4. A página de segurança do Curl observa:
“Esta falha faz com que o curl estoure um buffer baseado em heap no handshake do proxy SOCKS5. Quando o curl é solicitado a passar o nome do host para o proxy SOCKS5 para permitir que o endereço seja resolvido em vez de ser feito pelo próprio curl, o comprimento máximo desse nome do host pode ser de 255 bytes.
Se for detectado que o nome do host tem mais de 255 bytes, o curl alterna para a resolução de nome local e, em vez disso, passa o endereço resolvido apenas para o proxy. Devido a um bug, a variável local que significa “deixe o host resolver o nome” poderia obter o valor errado durante um handshake SOCKS5 lento e, ao contrário da intenção, copiar o nome do host muito longo para o buffer de destino em vez de copiar apenas o endereço resolvido lá.
Se o nome do host usado for maior que o buffer de destino, há um memcpy() que sobrescreve o buffer no heap. O analisador de URL e possivelmente uma biblioteca IDN (se o curl for construído com uma) precisam aceitar o nome do host, o que limita um pouco o conjunto de sequências de bytes disponíveis que podem ser usadas na cópia.
Notícias Relacionadas
Para que ocorra um overflow, é necessário um handshake SOCKS5 lento o suficiente para acionar o bug da variável local e o cliente usar um nome de host maior que o buffer de download. Talvez com um servidor HTTPS malicioso redirecionando para um URL especialmente criado. A latência típica do servidor é provavelmente “lenta” o suficiente para acionar esse bug sem que um invasor precise influenciá-lo pelo controle do servidor DoS ou SOCKS.”
O outro problema de segurança diz respeito apenas à injeção de cookies sem nenhum arquivo.
Enquanto isso, no lado dos recursos, o Curl 8.4 adiciona suporte para protocolos IPFS por meio de gateways HTTP. O Curl 8.4 também elimina o suporte para conjuntos de ferramentas legados do MinGW.org.
Mais detalhes sobre todas as alterações do Curl 8.4 via curl.se.
