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/
O agente ElementsClaw, da DAMO Academy, triou 2,4 milhões de estruturas cristalinas em 28 horas…
Pesquisadores da Universidade Tsinghua propõem treinar o resumo de contexto como parte da política do…
Pesquisadores da UC Berkeley e da IBM Research adaptaram o framework evolutivo K-Search para o…
Relatório trimestral da Microsoft Threat Intelligence mostra queda de 92% no phishing ligado à plataforma…
Pesquisa da Cisco Talos detalha o UAT-11795, grupo de língua russa que distribui instaladores adulterados…
Fundo ligado à TIM e Upload Ventures aporta na Enter, legal tech de IA brasileira.…