Como criei um heap overflow no Curl

• Artigo sobre a CVE-2023-38545, uma importante falha de segurança descoberta no curl 8.4.0, considerada o problema de segurança mais grave no curl em muito tempo
• O problema é um heap overflow causado por uma falha na função que se conecta a um proxy SOCKS5
• Esse problema foi introduzido no início de 2020, quando a função foi convertida de chamadas bloqueantes para uma máquina de estados não bloqueante, mudança feita para melhorar o desempenho de grandes transferências paralelas via SOCKS5
• A falha está no estado INIT da máquina de estados, onde uma variável local é configurada e decide se o curl resolverá o host localmente ou passará o nome ao proxy. Se o nome do host for longo demais, o código muda para o modo de resolução local, o que pode causar estouro de memória se o nome do host for maior que o buffer de destino
• O overflow pode ocorrer quando o tamanho do buffer é configurado para menos de 65541 bytes e o nome do host é maior que o tamanho do buffer. Isso exige que um agente malicioso forneça um nome de host extremamente grande para acionar a falha
• Um atacante que controle um servidor HTTPS acessado por um cliente que usa libcurl por meio de um proxy SOCKS5 pode provocar um heap buffer overflow ao retornar à aplicação um redirecionamento manipulado via resposta HTTP 30x
• O problema foi corrigido no curl 8.4.0 fazendo com que o curl retorne erro quando o nome do host for longo demais, em vez de mudar da resolução remota para a local. Também foi adicionado um caso de teste dedicado para esse cenário
• O autor reconhece que essa falha não teria ocorrido se o curl tivesse sido escrito em uma linguagem com segurança de memória em vez de C, mas afirma que portar o curl para outra linguagem não está nos planos atuais
• O autor sugere que permitir, usar e dar suporte a mais dependências escritas em linguagens com segurança de memória é uma abordagem viável e que, aos poucos, isso pode substituir partes do curl
• O autor admite o erro e pede desculpas, dizendo que essa falha poderia ter sido detectada com um conjunto de testes melhor. Ele também menciona analisadores estáticos de código que não encontraram o problema nessa função
• O autor conclui que disparar um heap overflow em um código instalado em mais de 20 bilhões de instâncias não é uma experiência recomendável

[GN⁺]

Opiniões do Hacker News

• Artigo sobre um problema de heap overflow na biblioteca Curl, usada em muitos dispositivos e escrita em sua maior parte por uma única pessoa.
• Daniel, autor do Curl, pede desculpas por um erro causado por uma falha que não foi encontrada no código por 1315 dias.
• O artigo sugere que problemas de segurança de memória poderiam ter sido evitados se o Curl tivesse sido escrito em uma linguagem com segurança de memória em vez de C.
• O autor considera a possibilidade de substituir gradualmente partes do Curl por uma linguagem mais segura em termos de memória, mas reconhece o ritmo lento desse tipo de desenvolvimento.
• O autor afirma que 41% das vulnerabilidades de segurança do Curl poderiam ter sido evitadas com uma linguagem segura em termos de memória.
• O artigo é reconhecido pela escrita clara e franca ao explicar a lógica e a perspectiva por trás do problema.
• Alguns comentários questionam a gravidade do problema, alegando que o vetor de ataque é muito pequeno e exige condições muito específicas para ser explorado.
• Um comentário critica a parte do código que pode expor a identidade do usuário via DNS para pessoas que usam ferramentas anticensura.
• Outro comentário aponta que o autor ignorou as restrições de hostname DNS especificadas na RFC1123, o que pode ter contribuído para o problema.
• É mencionado que a atualização de segurança mais recente do Windows 10 não incluiu uma versão nova do Curl.