O trio de falhas – CVE-2021-27363, CVE-2021-27364 e CVE-2021-27365 – espreitou no código do Linux desde 2006 sem detecção até que os pesquisadores do GRIMM os descobriram.
“Se você já executou em uma caixa, seja porque tem uma conta de usuário na máquina ou comprometeu algum serviço que não tem permissões reparadas, você pode fazer o que quiser basicamente”, disse Adam Nichols, diretor da prática de Segurança de Software na GRIMM.
Embora as vulnerabilidades “estejam em um código que não pode ser acessado remotamente, então isso não é como um exploit remoto”, disse Nichols, elas ainda são problemáticas. Eles aceitam “qualquer ameaça existente que possa estar lá. Isso só torna as coisas ainda piores ”, explicou ele. “E se você tiver usuários no sistema nos quais você realmente não confia com acesso root, ele também os quebra.”
Referindo-se à teoria de que ‘muitos olhos tornam todos os bugs superficiais’, o código do Linux “não está recebendo muitos olhos ou os olhos estão olhando para ele e dizendo que parece bom”, disse Nichols. “Mas, [os bugs] estão lá desde que o código foi escrito pela primeira vez e não mudaram realmente nos últimos 15 anos.”
Obviamente, os pesquisadores do GRIMM tentam “cavar” e ver há quanto tempo as vulnerabilidades existem quando podem – uma proposta mais viável com o código aberto.
O fato de as falhas terem escorregado na detecção por tanto tempo tem muito a ver com a expansão do kernel do Linux. “Ficou tão grande” e “há tanto código lá”, disse Nichols. “A verdadeira estratégia é ter certeza de que você está carregando o mínimo de código possível.”
Os bugs estão em todas as distribuições Linux, disse Nichols, embora o driver do kernel não seja carregado por padrão. Se um usuário normal pode carregar o módulo do kernel vulnerável varia. Eles podem, por exemplo, em todas as distros baseadas no Red Hat que o GRIMM testou, disse ele. “Mesmo que não seja carregado por padrão, você pode carregá-lo e, é claro, explorá-lo sem problemas.”
As vulnerabilidades existem em sistemas baseados em Debian também, mas são aproveitadas de forma diferente. Especificamente, quando o usuário tenta carregar esse driver, os scripts de configuração verificam se o hardware iSCSI está lá; se não estiver, a instalação será interrompida. Para a Red Hat, o driver será carregado, esteja o hardware lá ou não, disse Nichols.
Se o hardware estiver presente, entretanto, outros sistemas como Debian e Ubuntu “estão no mesmo barco que o Red Hat, onde o usuário, dependendo de quais pacotes estão instalados, pode forçá-lo a ser carregado; então está lá para ser explorado ”, disse ele.
Os bugs foram corrigidos nas seguintes versões do kernel : 5.11.4, 5.10.21, 5.4.103, 4.19.179, 4.14.224, 4.9.260 e 4.4.260. Todos os kernels mais antigos estão em fim de vida e não receberão patches.
Como uma medida temporária para neutralizar as falhas, Nichols recomenda colocar o kernel na lista negra se ele não estiver sendo usado. “Qualquer sistema que não use esse módulo pode simplesmente dizer para nunca carregar este módulo em nenhuma circunstância, e então você estará seguro”, disse ele. Mas “se você está realmente usando iSCSI, então não gostaria de fazer isso”.
Fonte: https://www.scmagazine.com/
Falha permite que invasores manipulem o agente de um usuário por meio de um problema…
Um exploit de dia zero, dirigido aos firewalls FortiGate da Fortinet, foi descoberto à venda…
A família SHELBY mostra um exemplo preocupante de malware moderno com design modular, sofisticado e…
Hackers estão explorando o diretório mu-plugins do WordPress para injetar códigos maliciosos que não aparecem…
O Google implementou uma nova funcionalidade de "Detecção de Golpes" com inteligência artificial no aplicativo…
O grupo APT28, ligado à Rússia, está utilizando técnicas avançadas de ofuscação em seus ataques…