Se han identificado tres vulnerabilidades que permiten a un atacante sin privilegios elevar sus privilegios en el sistema y ejecutar el código como root en systemd-journald el cual es el responsable del inicio de sesión en systemd.
Las vulnerabilidades se manifiestan en todas las distribuciones que usan systemd, con la excepción de SUSE Linux Enterprise 15, openSUSE Leap 15.0 y Fedora 28/29, en las cuales los componentes de systemd se ensamblan con la inclusión de «-fstack-clash-protection».
¿En qué consisten las vulnerabilidades?
Las vulnerabilidades ya registradas en CVE-2018-16864 y CVE-2018-16865 permiten crear condiciones para escribir datos fuera de los límites del bloque de memoria asignado, mientras que la vulnerabilidad CVE-2018-16866 permite leer el contenido de las áreas de memoria externa.
Los investigadores han preparado un prototipo funcional del exploit que, utilizando las vulnerabilidades CVE-2018-16865 y CVE-2018-16866.
A lo que se detalla sobre estas vulnerabilidades los investigadores nos dicen que esto permite obtener privilegios de root después de aproximadamente 10 minutos de ataque a sistemas con arquitectura i386 y 70 minutos en sistemas amd64.
Este exploit ha sido probado en Debian 9.5.
Así mismo nos explican que:
Cuando se escribe un exploit, se utiliza la técnica Stack Сlash, cuya esencia está en crear condiciones cuando el contenido del montón desbordado está en el área de pila o, a la inversa, la pila puede volver a escribir el área de montón.
Que se manifiesta en situaciones donde la pila y el montón se colocan adyacentes entre sí (el área de pila sigue inmediatamente la memoria asignada para el montón).
El exploit propuesto confirma el supuesto de que la protección contra ataques de la clase Stack Сlash en el nivel del Kernel de Linux no es suficiente.
Al mismo tiempo, el ataque se bloquea con éxito al reconstruir a GCC con la opción «-fstack-clash-protection» habilitada.
Sobre las vulnerabilidades
La vulnerabilidad CVE-2018-16864 se descubrió después de analizar la situación en la que la transferencia de aplicaciones que guardan datos en el registro a través de una llamada a syslog (), un gran número de argumentos de línea de comando (varios megabytes) lleva al colapso del proceso systemd-journald.
El análisis mostró que, al manipular una cadena con argumentos de línea de comando, se puede colocar una cola de pila controlada al comienzo de la pila.
Pero para un ataque exitoso, es necesario pasar por alto la técnica de protección de la página de protección de pila utilizada en el núcleo, cuya esencia está en la sustitución de las páginas de memoria de límites. para generar una excepción (error de página).
Para eludir esta protección en paralelo systemd-journald se inicia en “race condition”, dando tiempo para capturar proceso de control de colapsar debido a la entrada en la memoria de páginas, de sólo lectura.
En el proceso de estudio de la primera vulnerabilidad surgieron dos problemas más.
La segunda vulnerabilidad CVE-2018-16865 le permite crear condiciones de superposición de Stack Сlash similares escribiendo un mensaje muy grande en el archivo run/systemd/journal/socket.
La tercera vulnerabilidad CVE-2018-16866 se manifiesta si envía un mensaje de syslog con el último carácter «:».
Debido a un error en el análisis de la cadena, la cadena de terminación ‘\ 0’ después de que se descartará y el registro contendrá una porción de búfer fuera de ‘\ 0’, lo que le permitirá averiguar las direcciones de la pila y el mmap.
- La vulnerabilidad CVE-2018-16864 se manifiesta desde abril de 2013 (apareció en systemd 203), pero es adecuada para la operación solo después del cambio realizado a systemd 230 en febrero de 2016.
- La vulnerabilidad CVE-2018-16865 es evidente desde diciembre de 2011 (systemd 38) y está disponible para su funcionamiento a partir de abril de 2013 (systemd 201).
- Los problemas CVE-2018-16864 y CVE-2018-16865 se solucionaron hace unas horas en la rama maestra de systemd.
La vulnerabilidad CVE-2018-16866 apareció en junio de 2015 (systemd 221) y se corrigió en agosto de 2018 (no se muestra en systemd 240).
La publicación de un exploit de trabajo se pospuso hasta el lanzamiento de parches por distribuciones.
Actualmente, las distribuciones de vulnerabilidades aún no están parchadas son de las más populares tales como Debian, Ubuntu, RHEL, Fedora, SUSE, así como sus derivados.
systemd apesta!
init freedom… yeah!!!!