Systemd agora tem mais de 1.2 milhão de linhas de código

Systemd é um sistema de inicialização e um daemon que foi projetado especificamente para o kernel do Linux como uma alternativa ao daemon de inicialização do System V (sysvinit). Seu principal objetivo é fornecer um melhor framework para gerenciamento de dependências entre serviços, permitindo o carregamento paralelo de serviços na inicialização e reduzindo as chamadas para scripts Shell.

Depois de ultrapassar um milhão de linhas de código em 2017, o repositório Git do systemd indica que agora atinge 1.207.302 linhas de código. Essas 1.2 milhões de linhas estão espalhadas por 3,260 arquivos e consistem em 40,057 commits de quase 1,400 autores diferentes.

Systemd registrou um número recorde de commits no ano passado, mas até agora, é difícil imaginar que esse recorde pode ser quebrado em 2019.

Este ano, já houve 2 commits. No ano passado, as estatísticas mostraram 145, enquanto em 2016 e 2017 o sistema somava menos de pouco mais de quatro mil commits.

Lennart Poettering continua sendo o contribuidor mais proeminente para systemd com mais de 32% de confirmações até agora neste ano.

Depois dele, podemos descobrir que outros autores que seguem Lennart Poettering este ano são Yu Watanabe, Zbigniew Jędrzejewski-Szmek, Frantisek Sumsal, Susant Sahani e Evgeny Vereshchagin. Cerca de 142 pessoas contribuíram para a árvore de origem do Systemd desde o início do ano.

Systemd ainda não é apreciado por muitos

Embora hoje a maioria das distribuições GNU / Linux adote o systemd, isso foi fortemente criticado (e não é para os outros) por alguns membros da comunidade de código aberto, que acreditam que o projeto vai contra a filosofia do Unix e que seus desenvolvedores têm comportamento anti-Unix, porque o systemd é incompatível com todos os sistemas não Linux.

É por isso que É importante lembrar que o systemd estava na origem da divisão da comunidade Debian quando decidiu adotá-lo. como o sistema de inicialização padrão, apesar das ameaças de alguns contribuintes.

Com o qual antes de tais ações então eles deixaram o projeto Debian para criar um fork chamado Devuan (um Debian que não usa o systemd).

Para o objetivo principal do projeto é fornecer uma variante do Debian sem as complexidades e dependências do systemd, um sistema init e gerenciador de serviços originalmente desenvolvido pela Red Hat e posteriormente adotado pela maioria das outras distros.

E é que no início do ano informamos que algumas das principais distribuições do Linux eram vulneráveis ​​a alguns bugs do systemd.

Artigo relacionado:

Uma nova vulnerabilidade foi descoberta no Systemd

Entre parte dos erros que existiam, um deles estava no serviço 'journald', que coleta e armazena dados de log. Eles podem ser explorados para obter privilégios de root na máquina alvo ou para revelar informações.

Alguns desses erros foram descobertos por pesquisadores da empresa de segurança Qualys, as falhas eram duas vulnerabilidades de corrupção de memória (estouro de buffer de pilha - CVE-2018-16864 e alocação de memória ilimitada - CVE-2018-16865) e uma permitindo vazamento de informações (leitura fora dos limites, CVE-2018-16866).

Os pesquisadores desenvolveram um exploit para CVE-2018-16865 e CVE-2018-16866 que fornece um shell de raiz local em máquinas x86 e x64.

A façanha correu mais rápido na plataforma x86 e atingiu sua meta em dez minutos. Em x64, a exploração demorou 70 minutos.

A Qualys anunciou que planejava lançar o código de exploração PoC para demonstrar a existência de falhas e explicou em detalhes como era capaz de explorar essas falhas. Os pesquisadores também desenvolveram uma prova de conceito para o CVE-2018-16864 que permite assumir o controle do eip, a bandeira de instrução i386.

A vulnerabilidade de estouro de buffer (CVE-2018-16864) foi introduzida em abril de 2013 (systemd v203) e tornou-se explorável em fevereiro de 2016 (systemd v230).

Em relação à vulnerabilidade de alocação de memória ilimitada (CVE-2018-16865), foi introduzida em dezembro de 2011 (systemd v38) e tornada explorável em abril de 2013 (systemd v201), enquanto a vulnerabilidade de vazamento de memória (CVE-2018-16866) foi introduzida em Junho de 2015 (systemd v221) e foi corrigido inadvertidamente em agosto de 2018.