Estou com esse problema, estou tentando ver se um grupo de servidores está vulnerável ao CVE CVE-2024-1086 então o que faço no servidor é rpm -qa --changelog kernel | grep 2024-1086, e recebo isso como saída:
- netfilter: nf_tables: reject QUEUE/DROP verdict parameters (Florian Westphal) [RHEL-24009 2262126] {CVE-2024-1086}, o que acho que significa que o cve foi mitigado nesse sistema. Porém, o cliente diz que a varredura que eles estão usando para verificar se o sistema está vulnerável ainda está mostrando que o servidor está vulnerável, você sabe se com essa saída posso dizer que a varredura deles está dando um falso positivo ou existe alguma outra forma de confirmar com certeza que o sistema não está mais vulnerável a esse CVE?
Primeiro, acesse o banco de dados RedHat CVE e pesquise CVE-2024-1086. Isso o levará a esta página , que lista as erratas que corrigiram o CVE em cada versão do RHEL.
Para RHEL 8.x básico (ou seja, o nível de patch mais recente), será RHSA-2024-1607 e, para RHEL 8.8 Extended Update Support, será RHSA-2024-1404 .
Como você aparentemente está executando o RHEL 8.8 pelo número da versão do kernel, consulte a guia Pacotes Atualizados na página RHSA-2024-1404.
Ele informa que o pacote do kernel que primeiro continha o patch para sua versão é o
kernel-4.18.0-477.51.1.el8_8.x86_64.rpm.Você está executando a versão do kernel
4.18.0-477.55.1.el8_8.x86_64. O nível do patch477.55.1.el8_8é maior que477.51.1.el8_8, então sim, seu kernel está corrigido e você não está vulnerável.O scanner do cliente pode não ter conhecimento do Suporte Estendido do RHEL 8.8 e, portanto, "desejaria" ver a versão do kernel
4.18.0-513.24.1.el8_9.x86_64ou superior, o que seria a resposta se você tivesse atualizado para o RHEL 8.9 ou superior. Mas se você estiver usando o RHEL 8.8 Extended Support, o motivo mais comum para isso é que existe um aplicativo caro que ainda não suporta o RHEL 8.9 ou simplesmente o aplicativo não é certificado para ele e o cliente deseja/precisa do aplicativo em estado certificado.Uma versão do kernel não deve ser considerada uma única linha de incremento, mas um gráfico de árvore, pois pode haver várias subséries de kernel para fins especiais. Como você pode ver na página do banco de dados RedHat CVE com link acima, a série RHEL 8.x inclui pelo menos:
Todos eles têm seus próprios RPMs de kernel, com seus próprios números de nível de patch. Se você usar qualquer uma das séries de kernel para fins especiais, seu cliente deverá verificar se o scanner de vulnerabilidade também conhece essa série de kernel específica, ou você obterá falsos positivos.
Se houver dúvida se uma vulnerabilidade foi corrigida ou não, é importante verificar as informações mais recentes sobre o nível de patch aplicável no banco de dados CVE do fornecedor.
Verificar apenas o changelog do RPM pode indicar que uma vulnerabilidade foi corrigida, mas não dirá se os pesquisadores de segurança perceberam mais tarde "ops, descobriu-se que o patch inicial não fornecerá proteção completa, aqui está um patch melhor". Em situações como essa, o banco de dados CVE do fornecedor deve apontar diretamente para o patch posterior.
E assim, você pode ter certeza de que se o seu nível de patch RPM for igual ou superior ao nível relatado como corrigido no banco de dados CVE, e essa versão estiver realmente em execução, então a vulnerabilidade está bem e verdadeiramente corrigida de acordo com as melhores informações disponíveis.