Systemd es un sistema de inicialización y un daemon que ha sido diseñado específicamente para el Kernel de Linux como alternativa al daemon de inicio de System V (sysvinit). Su objetivo pirincipal es proporcionar un mejor marco para administrar las dependencias entre servicios, permitiendo la carga paralela de servicios en el inicio y reduciendo las llamadas a los scripts de Shell.
Después de superar un millón de lineas de código en el año 2017, el repositorio Git de systemd indica que ahora alcanza las 1.207.302 líneas de código. Estas 1.2 millones de líneas están distribuidas en 3,260 archivos y consisten en 40,057 confirmaciones de casi 1,400 autores diferentes.
Systemd registró un número récord de commits el año pasado, pero hasta ahora, es difícil imaginar que este récord podría romperse en 2019.
Este año, ya ha habido 2 145 commits. El año pasado, las estadísticas mostraron 6,245, mientras que en 2016 y 2017 el sistema totalizó menos un poco mas de cuatro mil commits.
Lennart Poettering sigue siendo el contribuidor más destacado para systemd con más del 32% de los commits en lo que va del año.
Después de el podremos encontrar que otros de los autores que le siguen a Lennart Poettering de este año son Yu Watanabe, Zbigniew Jędrzejewski-Szmek, Frantisek Sumsal, Susant Sahani y Evgeny Vereshchagin. Alrededor de 142 personas han contribuido al árbol fuente de Systemd desde principios de año.
Systemd sigue sin ser de agrado para muchos
Aunque hoy en día la mayoría de las distribuciones de GNU / Linux adoptan systemd, este ha sido fuertemente criticado (y no es por demás) por algunos miembros de la comunidad de código abierto, que creen que el proyecto va en contra del la filosofía de Unix y que sus desarrolladores tienen un comportamiento anti-Unix, porque systemd es incompatible con todos los sistemas que no son Linux.
Es por ello que es importante recordar que systemd estaba en el origen de la división de la comunidad de Debian cuando decidió adoptarlo como el sistema de inicialización predeterminado, a pesar de las amenazas de algunos contribuyentes.
Con lo cual ante tales acciones así que dejaron el proyecto Debian para crear un fork llamado Devuan (un Debian que no usa systemd).
Pues la meta primaria del proyecto es proveer una variante de Debian sin las complejidades y dependencias de systemd, un sistema init y un gestor de servicios originalmente desarrollado por Red Hat y posteriormente adoptado por la mayoría de las otras distros.
Y es que a principios de año informamos que algunas de las principales distribuciones de Linux fueron vulnerables a algunos errores de systemd.
Entre parte de los errores que existían, uno de ellos se encontraba en el servicio ‘journald’, que recopila y almacena datos de registro. Se podrían explotar para obtener privilegios de root en la máquina de destino o para revelar información.
Parte de estos errores fueron descubiertos por investigadores de la firma de seguridad Qualys, las fallas fueron dos vulnerabilidades de corrupción de memoria (desbordamiento de búfer en la pila – CVE-2018-16864 y asignación de memoria ilimitada – CVE-2018-16865) y una que permite fuga de información (lectura fuera de límites, CVE-2018-16866).
Los investigadores desarrollaron un exploit para CVE-2018-16865 y CVE-2018-16866 que proporciona una shell de root local en máquinas x86 y x64.
El exploit corrió más rápido en la plataforma x86 y alcanzó su objetivo en diez minutos. En x64, el exploit tardó 70 minutos.
Qualys había anunciado que planeaba lanzar el código de explotación PoC para demostrar la existencia de fallas y explicó en detalle cómo pudo aprovechar estas fallas. Los investigadores también desarrollaron una prueba de concepto para CVE-2018-16864 que le permite tomar el control de eip, el indicador de instrucción de i386.
La vulnerabilidad de desbordamiento de búfer (CVE-2018-16864) se introdujeron en abril de 2013 (systemd v203) y se hizo explotable en febrero de 2016 (systemd v230).
En cuanto a la vulnerabilidad de asignación de memoria ilimitada (CVE-2018-16865), se introdujo en diciembre de 2011 (systemd v38) y se hizo explotable en abril de 2013 (systemd v201), mientras que la vulnerabilidad de pérdida de memoria (CVE-2018-16866) se introdujo en junio de 2015 (systemd v221) y se corrigió inadvertidamente en agosto de 2018.
Fuente: desdelinux
