Projeto Openwall lançamento do módulo do núcleo (Linux Kernel Runtime Guard), destinado a detectar e bloquear ataques e violações da integridade das estruturas do núcleo. Por exemplo, o módulo pode proteger contra alterações não autorizadas no núcleo em funcionamento e tentativas de mudança de permissões de processos de usuários (definição de uso de exploits). O módulo é adequado tanto para estabelecer proteção contra exploits já conhecidos para o núcleo Linux (por exemplo, em situações onde é problemático atualizar o núcleo no sistema), quanto para resistir a exploits para vulnerabilidades ainda desconhecidas. Código do projeto sob a licença GPLv2.
Entre as mudanças na nova versão:
- Mudou o posicionamento do projeto LKRG, que agora não é dividido em subsistemas separados para verificação de integridade e detecção de uso de exploits, mas é apresentado como um produto coeso para detecção de ataques e diversas violações de integridade;
- Compatibilidade garantida com núcleos Linux de 5.3 a 5.7, bem como com núcleos compilados com otimizações agressivas do GCC, sem as opções CONFIG_USB e CONFIG_STACKTRACE ou com a opção CONFIG_UNWINDER_ORC, além de núcleos que não possuem funções LKRG interceptáveis, se puderem ser dispensadas;
- Durante a compilação, foi garantida a verificação de algumas configurações obrigatórias do núcleo CONFIG_* para gerar mensagens de erro significativas em vez de falhas obscuras;
- Suporte adicionado aos modos de espera (ACPI S3, suspensão para RAM) e hibernação (S4, suspensão para disco);
- Suporte ao DKMS adicionado ao Makefile;
- Suporte experimental implementado para plataformas ARM de 32 bits (testado no Raspberry Pi 3 Model B). O suporte anteriormente disponível para AArch64 (ARM64) foi complementado com a compatibilidade para a placa Raspberry Pi 4;
- Novos handlers (hook) adicionados, incluindo o handler de chamada capable() para melhor detecção de exploits que manipulam "" e não identificadores de processos ();
- Nova lógica proposta para detectar tentativas de saída das restrições de namespaces (por exemplo, de contêineres Docker);
- Em sistemas x86-64, verificação e aplicação do bit SMAP (Supervisor Mode Access Prevention) garantidos, destinado a bloquear o acesso a dados no espaço do usuário a partir de código privilegiado sendo executado no nível do núcleo. A proteção SMEP (Supervisor Mode Execution Prevention) foi implementada anteriormente;
- Durante a execução, garantido que as configurações do LKRG sejam posicionadas em uma página de memória normalmente acessível apenas para leitura;
- A saída de logs com informações que podem ser mais úteis para ataques (por exemplo, informações sobre endereços no núcleo) é limitada ao modo de depuração (log_level=4 ou superior), que está desativado por padrão.
- A escalabilidade do banco de dados de rastreamento de processos foi aumentada — em vez de uma única árvore RB protegida por um spinlock, foi implementada uma tabela hash com 512 árvores RB, protegidas por 512 bloqueios de leitura-escrita.
- Um modo foi implementado e ativado por padrão, no qual a verificação da integridade dos identificadores de processo é frequentemente realizada apenas para a tarefa atual, e opcionalmente para tarefas ativadas (despertadas). Para outras tarefas que estão em estado de suspensão ou em execução sem consultar a API LKRG no núcleo, a verificação é realizada com menos frequência.
- Novos sysctl e parâmetros de módulo foram adicionados para o ajuste fino do LKRG, além de dois sysctl para configuração simplificada através da seleção de conjuntos de ajustes finos preparados pelos desenvolvedores (profiles).
- As configurações padrão foram alteradas para alcançar um equilíbrio mais ponderado entre a agilidade na detecção de violações e eficiência na resposta, de um lado, e o impacto no desempenho e o risco de falsos positivos, do outro.
- O arquivo unit do systemd foi reformulado para carregar o módulo LKRG em um estágio inicial de inicialização (um parâmetro de linha de comando do núcleo pode ser usado para desativar o módulo).
Considerando as otimizações propostas na nova versão, a redução de desempenho ao aplicar o LKRG 0.8 é avaliada em cerca de 2,5% no modo padrão ('heavy') e 2% no modo leve ('light').
Recentemente, foi realizado sobre a eficácia dos pacotes para a detecção de rootkits LKRG obtendo os melhores resultados, sem falsos positivos, identificando 8 dos 9 rootkits testados que operam no nível do núcleo (foram detectados os rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit e Sutekh, mas o Keysniffer foi ignorado, pois é um módulo de núcleo com um keylogger, e não um rootkit no sentido estrito). Em comparação, os pacotes AIDE, OSSEC e Rootkit Hunter detectaram 2 rootkits de 9, enquanto o Chkrootkit não detectou nenhum. Vale ressaltar que o LKRG não suporta a detecção de rootkits que estão localizados no espaço do usuário, portanto, a maior eficácia é alcançada ao usar a combinação AIDE e LKRG, que permitiu a detecção de 14 dos 15 rootkits de todos os tipos.
Adicionalmente, pode-se destacar que o desenvolvedor da distribuição comecei de pacotes prontos com DKMS para Debian, Whonix, Qubes e Kicksecure, e o pacote para já foi atualizado para a versão 0.8. Pacotes com LKRG também estão disponíveis em distribuições russas. e .
A verificação de integridade no LKRG é realizada com base na comparação entre o código atual e os dados do kernel e dos módulos, algumas estruturas de dados importantes e configurações da CPU com hashes salvos ou cópias das áreas de memória, estruturas de dados ou registradores correspondentes. As verificações são ativadas tanto periodicamente por um temporizador quanto ao ocorrer vários eventos.
A identificação de possíveis aplicações de exploits e o bloqueio de ataques ocorrem na fase antes de o kernel conceder acesso a recursos (por exemplo, antes de abrir um arquivo), mas após o processo obter permissões não autorizadas (por exemplo, mudança de UID). Ao detectar comportamento não autorizado dos processos, por padrão, estes são encerrados forçadamente, o que é suficiente para bloquear muitos exploits.
Fonte: opennet.ru
