O propósito de reportar vulnerabilidades que já foram corrigidas anos atrás ainda é desconhecido
Daniel Stenberg, enrolar Autor, alertou os usuários, por meio de uma postagem no blog, sobre um relatório pela organização MITRE, de uma falsa vulnerabilidade crítica.
O informe detalhes sobre uma vulnerabilidade à qual o CVE-ID "CVE-2020-19909" foi atribuídoe um nível de gravidade de 9,8 em 10, típico de vulnerabilidades exploradas remotamente que levam à execução elevada de código.
No relatório de vulnerabilidade um bug é referenciado no código de análise da opção de linha de comando “–retry-delay”, que foi corrigido em 2019 e causou um estouro de número inteiro. Como o bug só se manifesta quando um valor incorreto é passado explicitamente ao executar o utilitário a partir da linha de comando e leva a uma interpretação incorreta do atraso antes do reenvio dos dados, o bug não foi classificado como uma vulnerabilidade pelos desenvolvedores.
Esta é uma história que consiste em vários pequenos blocos de construção e eles ocorreram espalhados ao longo do tempo e em diferentes lugares. É uma história que mostra claramente como nosso sistema atual com ID CVE e muito poder dado ao NVD é um sistema completamente quebrado.
Daniel Stenberg, menciona que o problema chega três anos depois quando alguém enviou um relatório de vulnerabilidade ao MITRE e atribuiu ao problema um nível de gravidade crítico.
Então, em sua postagem, critica MITRE, já que diz isso como é possível que esta organização “aceite o nível de severidade indicado”, porque mesmo que fosse uma vulnerabilidade explorável, os problemas de negação de serviço geralmente se enquadram em outra categoria.
Nós, do projeto curl, trabalhamos arduamente e com afinco em segurança e sempre trabalhamos com pesquisadores de segurança que relatam problemas. Apresentamos nossos próprios CVEs, documentamos e divulgamos ao mundo sobre eles. Listamos mais de 140 deles com todos os detalhes possíveis sobre eles fornecidos. Nosso objetivo é fornecer documentação de nível ouro para tudo, incluindo nossas vulnerabilidades de segurança anteriores.
O fato de outra pessoa ter enviado repentinamente um CVE para curl é uma surpresa. Isso não nos foi dito e nós realmente teríamos gostado. Agora há um novo CVE relatando um problema de curl e não temos detalhes a dizer sobre isso no site. Não é bom.
É digno de nota que os desenvolvedores do curl recorreram ao MITRE com um pedido para cancelar o relatório CVE, mas os representantes do MITRE simplesmente cancelaram a inscrição e recusaram-se a remover o CVE e apenas o marcaram como polêmico ("DISPUTADO").
Além disso, é referido que os “relatórios controversos” são enviados anonimamente através do serviço de reporte de vulnerabilidades “NVD” e como tal até ao momento não se sabe ao certo o motivo da publicação deste tipo de “falsas vulnerabilidades”.
Muitos dos que comentaram na postagem do autor do Curl, eles parecem chegar a um certo ponto, pois mencionam que provavelmente alguém decidiu provar a falta de uma auditoria adequada ao receber relatórios de vulnerabilidades, a capacidade de usar o CVE como um mecanismo para desacreditar projetos ou chamar a atenção para corrigir problemas potencialmente perigosos no código sem analisar seu impacto na segurança.
E é que até Jonathan White, da equipe KeePassXC, sob o apelido de “droidmonkey”, fez um comentário no qual se refere ao fato de a equipe KeePassXC também ter passado por um problema semelhante, o que reforça a ideia de que o mais É é provável que alguém tenha preparado relatórios com base no estudo de bugs corrigidos que poderiam levar a vulnerabilidades, mas que os desenvolvedores dos principais projetos reconheceram como não afetando a segurança (por exemplo, pode haver um buffer overflow, mas só se manifesta durante o processamento dados internos que não podem ser influenciados pelo usuário).
finalmente se você está interessado em saber mais sobre o assunto, você pode verificar os detalhes no link a seguir