Uma nova vulnerabilidade foi descoberta no Systemd

Foi encontrada uma vulnerabilidade no systemd que já está descrita em (CVE-2019-6454), do que permite fazer com que o processo de inicialização do controle (PID1) bloqueie ao enviar uma mensagem especialmente criada para um usuário sem privilégios através do D-Bus.

Os Os desenvolvedores da Red Hat também não excluem a possibilidade de usar a vulnerabilidade para organizar a execução do código com privilégios de root., mas a possibilidade final de tal ataque ainda não foi determinada.

Sobre o systemd

Para quem não conhece o Systemd Posso dizer-lhe isso este é um sistema de inicialização do Linux e gerenciador de serviços que inclui recursos como inicialização de daemon sob demanda, montagem automática e manutenção de ponto de montagem, suporte de instantâneo e rastreamento de processo usando grupos de controle do Linux.

Systemd fornece um daemon de registro e outras ferramentas e utilitários para ajudar nas tarefas comuns de administração do sistema. Lennart Poettering e Kay Sievers escreveram o SystemD, inspirado no macOS launchd e Upstart, com o objetivo de criar um sistema moderno e dinâmico.

Em particular, o systemd fornece recursos de paralelização agressivos e lógica de controle de serviço baseada em dependência, permitindo que os serviços sejam iniciados em paralelo e levando a tempos de inicialização mais rápidos. Esses dois aspectos estavam presentes no Upstart, mas aprimorados pelo systemd.

Systemd é o sistema de inicialização padrão para as principais distribuições Linux, mas é compatível com os scripts de inicialização SysV.

SysVinit é um sistema de inicialização que precede o systemd e usa uma abordagem simplificada para iniciar o serviço. O Systemd não apenas gerencia a inicialização do sistema, mas também fornece alternativas para outros utilitários conhecidos, como cron e syslog.

Sobre a nova vulnerabilidade do systemd

Ao manipular o tamanho da mensagem enviada pelo D-Bus, um invasor pode mover o ponteiro além dos limites de memória alocada para a pilha, contornando a proteção da "página de guarda da pilha", que se baseia na substituição de uma página de memória na borda que chama uma exceção (falha de página).

O ataque bem-sucedido é demonstrado no Ubuntu 18.10 com systemd 239 e no CentOS 7.6 com systemd 219.

Como solução alternativa, a compilação pode ser usada no GCC com a opção "-fstack-clash-protection", que é usada por padrão no Fedora 28 e 29.

Ressalta-se que em 2014 o autor da biblioteca do sistema MUSL apontou entre os principais problemas arquitetônicos do manipulador PID1 de inflação excessiva do sistema e questionou a viabilidade de implementação de um controlador de nível PID1 API para Link com o Barramento, por ser um vetor sério ataques e podem afetar adversamente a confiabilidade de todo o sistema

De acordo com um pesquisador de segurança que revelou uma vulnerabilidade, uma mudança de ponteiro de pilha só é possível para páginas de memória não utilizadas (não atribuído), que não permite organizar a execução do código no contexto do processo PID1, mas permite que um invasor inicie o bloqueio PID1 com uma subsequente transição do kernel Linux para o estado de "pânico" (no caso do controlador PID 1 falha, todo o sistema trava).

No systemd, um manipulador de sinal é instalado que tenta capturar as falhas do processo PID1 (falha de segmentação) e inicia o shell para recuperação.

Mas, uma vez que, durante o ataque, uma chamada é feita para páginas de memória não duplicadas (não alocadas), o kernel não pode chamar este manipulador de sinal e apenas termina o processo com PID 1, que por sua vez o faz. É impossível continuar trabalhando e ir para o estado de "pânico", portanto, é necessário reiniciar o sistema.

Já existe uma solução para o problema

Como todo problema de segurança já descrito e relatado, sua publicação não pode ser feita até que o problema seja resolvido e atualizações de patch de vulnerabilidade para SUSE / openSUSE, Fedora já foram lançadas, também para Ubuntu e parcialmente para Debian (Somente Debian Stretch).
Embora o problema permaneça sem correção no RHEL.