Fue encontrada una vulnerabilidad en systemd la cual ya esta descrita en (CVE-2019-6454), que permite provocar el bloqueo del proceso de inicialización de control (PID1) al enviar un mensaje especialmente diseñado a un usuario sin privilegios a través del D-Bus.

Los desarrolladores de Red Hat tampoco excluyen la posibilidad de utilizar la vulnerabilidad para organizar la ejecución del código con privilegios de root, pero aún no se ha determinado la posibilidad final de tal ataque.

Sobre systemd

Para quienes no conozcan Systemd les puedo decir que este es un sistema de inicialización de Linux y administrador de servicios que incluye funciones como el inicio a pedido de demonios, el mantenimiento de puntos de montaje y montaje automático, el soporte de instantáneas y el seguimiento de procesos utilizando grupos de control de Linux.

Systemd proporciona un demonio de registro y otras herramientas y utilidades para ayudar con las tareas comunes de administración del sistema. Lennart Poettering y Kay Sievers escribieron SystemD, inspirado por macOS launchd y Upstart , con el objetivo de crear un sistema moderno y dinámico.

En particular, systemd proporciona capacidades de paralelización agresivas y una lógica de control de servicio basada en la dependencia, permitiendo que los servicios se inicien en paralelo y lo que lleva a un tiempo de arranque más rápido. Estos dos aspectos estaban presentes en Upstart, pero mejorados por systemd.

Systemd es el sistema de inicio predeterminado para las principales distribuciones de Linux, pero es compatible con versiones anteriores de los scripts de inicio SysV.

SysVinit es un sistema de inicialización que precede a systemd y utiliza un enfoque simplificado para iniciar el servicio. Systemd no solo administra la inicialización del sistema, sino que también proporciona alternativas para otras utilidades bien conocidas, como cron y syslog.

Sobre la nueva vulnerabilidad de systemd

Al manipular el tamaño del mensaje enviado a través del D-Bus, un atacante puede mover el puntero más allá de los límites de la memoria asignada para la pila, omitiendo la protección de “stack guard-page”, que se basa en la sustitución de una página de memoria en el borde que llama una excepción (fallo de página).

El ataque exitoso se demuestra en Ubuntu 18.10 con systemd 239 y en CentOS 7.6 con systemd 219.

Como solución alternativa, la compilación se puede usar en GCC con la opción “-fstack-clash-protection”, que se usa por defecto en Fedora 28 y 29.

Cabe señalar que en 2014 el autor de la MUSL biblioteca del sistema señalado entre los principales problemas arquitectónicos systemd inflación excesiva manejador PID1 y puso en duda la viabilidad de implementar un nivel PID1 controlador de API de Enlace con el Bus, ya que es un vector seria para los ataques y puede afectar negativamente a la fiabilidad de la totalidad sistema

De acuerdo con un investigador de seguridad que reveló una vulnerabilidad, un cambio del puntero de pila es posible solo para páginas de memoria no utilizadas (no asignadas), lo que no permite organizar la ejecución de código en el contexto del proceso PID1, pero permite que un atacante inicie el bloqueo de PID1 con una subsiguiente transición del kernel de Linux al estado de “panic” (en el caso de un fallo del controlador PID 1, se bloquea el sistema completo).

En systemd, se instala un controlador de señales que intenta interceptar las fallas del proceso PID1 (segmentation fault) e inicia el shell para la recuperación.

Pero ya que, durante el ataque, se realiza una llamada a páginas de memoria no duplicadas (no asignadas), el kernel no puede llamar a este controlador de señales y simplemente finaliza el proceso con PID 1, lo que, a su vez, hace imposible continuar trabajando y pasar al estado de “panic”, por lo que se requiere de un reinicio del sistema.

Ya existe una solución para el problema

Como todo problema de seguridad ya descrito e informado, su publicación no puede ser realizada hasta haber solucionado el problema y las actualizaciones de parches de vulnerabilidad para SUSE / openSUSE , Fedora ya fueron liberados, asi mismo también para Ubuntu y en parte para Debian (solo para Debian Stretch).
Aun que el problema permanece sin corregir en RHEL.

El artículo Fue descubierta una nueva vulnerabilidad en Systemd aparece primero en Fue descubierta una nueva vulnerabilidad en Systemd.