.
Após uma semana de especulações desenfreadas sobre a natureza dos problemas de segurança do curl, a versão mais recente da ferramenta de transferência de linha de comando foi finalmente lançada hoje.
Descritos pelo fundador do projeto curl e desenvolvedor líder Daniel Stenberg como “provavelmente a pior falha de segurança curl em muito tempo”, os patches abordam duas vulnerabilidades separadas: CVE-2023-38545 e CVE-2023-38546.
Agora sabemos que a primeira vulnerabilidade, CVE-2023-38545, é uma falha de buffer overflow baseada em heap que afeta tanto o libcurl quanto a ferramenta curl, com uma classificação de gravidade “alta”. Os possíveis resultados de tais problemas incluem a corrupção de dados e, nos piores casos, a execução de código arbitrário.
Especificamente, o buffer overflow pode ocorrer durante um handshake lento do proxy SOCKS5. A vulnerabilidade foi acionada devido ao manuseio incorreto de nomes de host com mais de 255 bytes.
Quando um nome de host excede 255 bytes, curl alterna para resolução local em vez de permitir que o proxy resolva o nome de host remotamente.
“Devido a um bug, a variável local que significa ‘deixe o host resolver o nome’ pode 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á”, o consultivo lê.
curl disse que a vulnerabilidade provavelmente poderia ser explorada sem a necessidade de um ataque de negação de serviço ou para que os bandidos obtenham o controle do servidor SOCKS, já que a latência típica de um servidor é lenta o suficiente.
Um invasor poderia explorar essa vulnerabilidade de maneira viável usando um servidor HTTPS malicioso redirecionando para uma URL criada especificamente para acionar o estouro de buffer de heap, disse.
Os aplicativos que dependem do libcurl 7.69.0 até 8.3.0 inclusive – a versão anterior mais recente – são aconselhados a atualizar para 8.4.0 o mais rápido possível. Aqueles com aplicativos que não definiram o tamanho do buffer de recebimento preferencial (CURLOPT_BUFFERSIZE), ou aqueles que o definiram como menores que 65.541 bytes, são especialmente vulneráveis.
A configuração padrão da ferramenta curl protege contra a vulnerabilidade por padrão, mas os aplicativos que dependem do libcurl podem precisar fazer alterações.
Agora corrigido na versão 8.4.0, o patch garante que um erro seja retornado quando nomes de host com mais de 255 bytes forem encontrados.
curl também desaconselhou o uso CURLPROXY_SOCKS5_HOSTNAME proxies e definir uma variável de ambiente de proxy para o esquema Socks5h://.
“Lendo o código agora é impossível não ver o bug”, disse Stenberg em um blog. “Sim, realmente dói ter que aceitar o fato de que cometi esse erro sem perceber e que a falha permaneceu desconhecida no código por 1.315 dias. Peço desculpas. Sou apenas um humano.
“Poderia ter sido detectado com um conjunto melhor de testes. Executamos repetidamente vários analisadores de código estático no código e nenhum deles detectou problemas nesta função.
“Em retrospectiva, enviar um heap overflow em código instalado em mais de 20 bilhões de instâncias não é uma experiência que eu recomendaria.”
Vulnerabilidade número dois
A segunda vulnerabilidade, CVE-2023-38546, é uma falha de injeção de cookie menos grave e afeta apenas o libcurl.
O projeto curl consultivo diz que a probabilidade de um invasor atender à série de condições necessárias para acionar a vulnerabilidade é baixa e acrescenta que, mesmo que o fizesse, o risco de um ataque de injeção de cookies à segurança de um usuário também é baixo.
Para facilitar as transferências, libcurl possui uma função chamada curl_easy_duphandle que é responsável por duplicar “easy handles” – identificadores individuais para transferências únicas.
“Se uma transferência tiver cookies ativados quando o identificador for duplicado, o estado de ativação de cookies também será clonado – mas sem clonar os cookies reais”, diz o comunicado.
“Se o identificador de origem não lesse nenhum cookie de um arquivo específico no disco, a versão clonada do identificador armazenaria o nome do arquivo como ‘nenhum’ (usando as quatro letras ASCII, sem aspas).”
Se esse identificador clonado fosse usado novamente, ele carregaria cookies de um arquivo chamado “none”, desde que estivesse no formato de arquivo correto e existisse no diretório do programa usando libcurl.
As versões afetadas são libcurl 7.9.1 até 8.3.0 inclusive. Os usuários são aconselhados a atualizar para o curl 8.4.0 e ligar curl_easy_setopt(cloned_curl, CURLOPT_COOKIELIST, "ALL"); depois de cada chamada para curl_easy_duphandle();.
Divulgação descoordenada
Os patches foram originalmente programados para lançamento hoje às 06:00 UTC, mas um mantenedor do projeto divulgou os detalhes do patch para CVE-2023-38545 horas antes do horário programado de entrada em operação.
O início vazar veio do projeto CentOS Stream da Red Hat no GitLab e seu tempo de confirmação confirmou que foi feito às 17h25 UTC de 10 de outubro, em vez da data e hora de lançamento agendada.
Os pesquisadores de segurança rapidamente tentaram entender como as vulnerabilidades poderiam ser exploradas usando as informações destacadas na comparação.
John Hammond documentado suas tentativas em um tópico X (anteriormente Twitter), mas suas tentativas, que encontraram alguns pequenos erros, no final das contas não revelaram uma exploração prejudicial.
Katie Moussouris, CEO da Luta Security, disse divulgações coordenadas de vulnerabilidades podem ser “negócios complicados, especialmente quando há fusos horários envolvidos”.
Segurança de memória
A ideia de que aplicativos escritos em linguagens de programação com menos proteções de segurança de memória deveriam ser reescritos em linguagens mais recentes, como Rust and Go, já existe há muito tempo na indústria.
Apelos mais fortes para fazer a mudança surgiram recentemente dos EUA, com a Agência de Segurança Nacional (NSA) publicando sua recomendação ano passado.
Ele levantou preocupações sobre o número de vulnerabilidades relacionadas à segurança da memória que estavam sendo exploradas, citando a admissão da Microsoft e do Google de que cerca de 70% das vulnerabilidades estão enraizadas em problemas de segurança da memória.
Stenberg admitiu que as falhas encontradas no curl não teriam existido se ele tivesse sido escrito em uma linguagem com mais memória segura em vez de C, mas confirmou que não havia planos para fazer tal mudança.
A abordagem do curl continuará sendo aquela que “permite, usa e oferece suporte a linguagens seguras para memória”, disse Stenberg, e a ambição de substituir o back-end HTTP do curl pelo Ferrugem-coded Hyper ainda está sendo considerado.
“No entanto, tal desenvolvimento está acontecendo atualmente em uma velocidade quase glacial e mostra com dolorosa clareza os desafios envolvidos. Curl permanecerá escrito em C no futuro próximo.
“Todos que não estão satisfeitos com isso são, obviamente, bem-vindos a arregaçar as mangas e começar a trabalhar”, acrescentou. ®
.
