De acordo com pesquisadores de segurança, vulnerabilidades do Linux poderia ser totalmente mitigados ou “diminuiu” para “menos-que-crítica” gravidade através de um design OS, que é baseado em um microkernel Verificado.
Para provar seu ponto, um grupo de pesquisadores acadêmicos e apoiados pelo governo realiza um estudo exaustivo sobre falhas críticas do Linux. Suas descobertas provam que dificilmente há uma falha que não possa ser mitigada para menos do que crítica. além disso, o estudo revela que 40% de falhas poderia ser totalmente exterminado, com a ajuda de um microkernel verificado. Os pesquisadores formam um grupo da Data61, Organização de Pesquisa Industrial e Científica da Commonwealth do governo australiano (CSIRO) e a Universidade de Nova Gales do Sul em Sydney.
O estudo está prestes a ser apresentado durante a APSys 2018 (Workshop da ACM Ásia-Pacífico sobre Sistemas). O jornal deles diz que:
Os benefícios de segurança de manter a base de computação confiável de um sistema (TCB) pequeno tem sido aceito como um truísmo, assim como o uso de limites internos de proteção para limitar os danos causados por explorações. Aplicado ao sistema operacional, isso defende um pequeno microkernel como o núcleo do TCB, com serviços de SO separados em componentes mutuamente protegidos (servidores) – em contraste com designs 'monolíticos'.
Confiar em um design de microkernel torna a maioria dos componentes isolados uns dos outros, executando com privilégios de segurança reduzidos. Isso faz com que mais difícil para uma vulnerabilidade levar ao comprometimento de todo o sistema. Isso também fornece controle refinado sobre os direitos de acesso no sistema, permitindo assim um design de privilégio mínimo, pesquisadores apontar. Isso, por sua vez, fornece controle refinado sobre os direitos de acesso no sistema, e permite um verdadeiro design de privilégio mínimo.
Em um SO monolítico, comprometendo um (fornecido pelo kernel) serviço compromete todo o sistema, portanto, todo o kernel de vários milhões de SLOC está no TCB de cada aplicativo. Em contraste, em um sistema baseado em microkernel, o TCB de um aplicativo se torna altamente dependente dos serviços do sistema que ele usa.
Esta regra também pode ser aplicada ao Windows e macOS, mesmo que o artigo seja focado apenas no Linux. O núcleo do Windows, por exemplo, está se tornando maior, com uma versão recente dita ser 60 para 65 MSLOC, o papel diz.
Como a pesquisa foi conduzida?
Os pesquisadores analisaram cada falha crítica de segurança no kernel Linux que está listado no repositório CVE em 2017. Com esta análise, os pesquisadores queriam ver se uma abordagem de microkernel melhoraria o estado de segurança. Suas descobertas mostram que 96% de bugs críticos do Linux deixariam de ser críticos se um design baseado em microkernel for introduzido. além disso, 40% dessas falhas podem ser completamente eliminadas com um microkernel verificado, e 29% seria exterminado com um microkernel não verificado.
Um bom exemplo aqui é a falha CVE-2015-4001 que é descrita como um estouro de buffer na função stellaris_enet_receive em hw/net/stellaris_enet.c no QEMU, quando o controlador ethernet Stellaris está configurado para aceitar pacotes grandes. A vulnerabilidade permite que invasores remotos causem uma negação de serviço (Falha QEMU) através de um grande pacote.
Pelo visto, esta vulnerabilidade é completamente eliminada por um microkernel:
Um exemplo desta categoria é o CVE-2015-4001, que descreve um erro de assinatura de inteiro no driver OZWPAN. Este driver é um driver de dispositivo controlador de host USB que não possui um dispositivo de hardware associado a ele, mas, em vez disso, é usado para se comunicar com um periférico sem fio por Wi-Fi. O erro de sinal inteiro pode fazer com que o resultado de uma subtração se torne negativo, fazendo com que uma operação memcpy interprete o valor como uma intenção de copiar grandes quantidades de dados fornecidos pela rede em um buffer de heap. Um invasor pode inserir uma carga útil em um pacote criado para acionar o erro e injetar dados. Como o Linux carrega o driver no kernel, pode causar uma negação de serviço ao travar o kernel, ou poderia executar código arbitrário com privilégios de kernel.
Para divulgação técnico completo, consulte a íntegra papel.
Milena Dimitrova
Um escritor inspirado e gerente de conteúdo que está com SensorsTechForum desde o início do projeto. Um profissional com 10+ anos de experiência na criação de conteúdo envolvente. Focada na privacidade do usuário e desenvolvimento de malware, ela acredita fortemente em um mundo onde a segurança cibernética desempenha um papel central. Se o senso comum não faz sentido, ela vai estar lá para tomar notas. Essas notas podem mais tarde se transformar em artigos! Siga Milena @Milenyim
Me siga: