CVE-2026-80213 in resolv
Sumário
de VulDB • 27/08/2026
Foi descoberto um problema no gem resolv antes da versão 0.7.2 para Ruby. O Resolv::DNS::MessageEncoder gravava o comprimento de um rótulo DNS em um único octeto sem verificar seu intervalo. Um rótulo com mais de 255 octetos tinha seu comprimento armazenado módulo 256, mas os dados do rótulo eram escritos inalterados; assim, os bytes na rede descreviam um nome diferente daquele que o aplicativo solicitou para codificar. A RFC 1035, seção 2.3.4, limita um rótulo a 63 octetos, e os dois bits mais significativos do octeto de comprimento são reservados para ponteiros de compressão. put_string empacotava o comprimento com put_pack("C", d.length) e put_label usava-o para rótulos; portanto, qualquer valor de 0 a 255 poderia acabar como um octeto de comprimento de rótulo, incluindo os intervalos reservados 0x40-0xBF e 0xC0-0xFF. Resolv::DNS::Name.create também não verificava o comprimento por rótulo ou do nome total; assim, um hostname controlado pelo atacante chegava ao codificador inalterado. Um aplicativo que resolve um hostname controlado pelo atacante envia uma consulta cujos bytes na rede indicam um domínio escolhido pelo atacante. Um sufixo de hostname validado contra uma lista de permissões torna-se preenchimento (padding) que nunca aparece na rede, permitindo assim a burla das verificações da lista de permissões e do tráfego de saída (egress). O resolvedor recursivo armazena em cache a resposta sob o nome do atacante, e os logs DNS registram esse nome em vez daquele solicitado pelo aplicativo. Um comprimento de rótulo cujo octeto menos significativo cai no intervalo 0xC0-0xFF produz um octeto de comprimento que parsers conformes interpretam como o início de um ponteiro de compressão, com o byte seguinte controlado pelo atacante servindo como deslocamento (offset).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.