nova versão da ferramenta para receber e enviar dados pela rede — , que permite a formação flexível de solicitações com a definição de parâmetros como cookie, user_agent, referer e quaisquer outros cabeçalhos. cURL suporta HTTP, HTTPS, HTTP/2.0, HTTP/3, SMTP, IMAP, POP3, Telnet, FTP, LDAP, RTSP, RTMP e outros protocolos de rede. Ao mesmo tempo, foi lançada uma atualização da biblioteca libcurl, que fornece uma API para utilizar todas as funções do curl em programas em linguagens como C, Perl, PHP, Python.
A nova versão adicionou a opção "—retry-all-errors" para realizar tentativas de execução de operações ao ocorrer quaisquer erros e resolveu duas vulnerabilidades:
- permite sobrescrever um arquivo local no sistema ao acessar um servidor controlado pelo atacante. O problema se manifesta apenas quando as opções "-J" ("—remote-header-name") e "-i" ("—head") são usadas simultaneamente. A opção "-J" permite salvar o arquivo com o nome especificado no cabeçalho
"Content-Disposition". Se um arquivo com esse nome já existir, o programa curl normalmente se recusa a sobrescrever, mas se a opção "-i" estiver presente, a lógica de verificação é violada e o arquivo é sobrescrito (a verificação é realizada na fase de recebimento do corpo da resposta, mas com a opção "-i" os cabeçalhos HTTP são exibidos inicialmente e conseguem ser salvos antes do início do processamento do corpo da resposta). Apenas os cabeçalhos HTTP são gravados, mas o servidor pode retornar dados aleatórios em vez dos cabeçalhos e eles serão salvos. - pode levar ao vazamento no servidor DNS de algumas senhas de acesso ao site (Basic, Digest, NTLM, etc.). Ao usar o caractere "@" na senha, que também é utilizado como separador de senha na URL, ao ativar o redirecionamento HTTP, o curl enviará a parte da senha após o caractere "@" juntamente com o domínio para determinar o nome. Por exemplo, ao especificar a senha "passw@rd123" e o nome de usuário "dan", o curl gerará a URL "https://dan:passw@rd123@example.com/path" em vez de "https://dan:passwrd123@example.com/path" e enviará uma solicitação para resolver o host "rd123@example.com" em vez de "example.com".
O problema ocorre ao ativar o suporte a redirecionamentos HTTP relativos (desativados através de CURLOPT_FOLLOWLOCATION). No caso de uso de DNS tradicionais, informações sobre parte da senha podem ser obtidas pelo provedor de DNS e por atacantes que têm a capacidade de interceptar o tráfego de rede em trânsito (mesmo que a solicitação original tenha sido feita via HTTPS, uma vez que o tráfego DNS não é criptografado). Ao utilizar DNS-over-HTTPS (DoH), o vazamento é limitado ao operador de DoH.
Fonte: opennet.ru
