EDICIóN GENERAL
24 meneos
202 clics
Este envío tiene varios votos negativos. Asegúrate antes de menear
Nuevo fallo en la escalada de privilegios de Systemd afecta a la mayoría de las distribuciones de GNU/Linux

Nuevo fallo en la escalada de privilegios de Systemd afecta a la mayoría de las distribuciones de GNU/Linux

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”.

| etiquetas: linux , systemd , vulnerabilidad
#12 Yo administro unos cuantos servidores Linux y no le he visto ventaja. De hecho, me complica algunos "toqueteos" que antes hacía fácilmente.
#14 ¿Cuáles?
#15 pues por ejemplo antes era trivial modificar los scripts que arrancan programas. Eso sin contar con que ahora han metido procesos de parada y arranque en binarios compilados que requerirían recompilar para modificarlos.
Otra cosa molesta es que cuando modificas algo hay que hacer que relea los cambios manualmente porque si no sigue como antes.
#16 Ahora sigue siendo trivial. Antes necesitabas saber bash (o cualquier lenguaje de script), ahora necesitas saber son las distintas opciones de configuración para montar las units. La diferencia es que las units te lo dan (casi) todo lo que pudieras necesitar hecho.

Y eso de los procesos de parada y arranque en binarios... los procesos de arranque y parada los defines tú como quieras y quien lo hace al fin y al cabo es la aplicación, systemd sólo da un framework para realizarlo de manera…   » ver todo el comentario
#18 Mira, por ejemplo ayer tenía un problema: necesitaba agregarle un LD_LIBRARY_PATH al apache (para que funcionara el módulo de Oracle para PHP). En todas partes decía que era simplemente ponerlo en el /etc/sysconfig/apache. Claro: en un script de arranque "normal" hacia un . /etc/sysconfig/apache, con lo que cualquier variable de entorno que agregaras ahí pasaba a estar en el entorno del apache al arrancar. Pero por lo visto systemd no hace eso así que no me tomaba nada que pusiera ahí.
#19 Aquí lo mismo hombre. Con añadir entradas Environment...

[Unit]
Description=My Daemon

[Service]
Environment="FOO=bar baz"
ExecStart=/bin/myforegroundcmd

[Install]
WantedBy=multi-user.target


Si no quieres fijar el valor de la variable de entorno estáticamente (y recargar la unit en caso de modificarla), también puedes cargarla desde un fichero externo:

[Service]
EnvironmentFile=/ruta/al/archivo
#14
Debes ser todo un gurú, utilizando servidores Linux en vez de GNU. Linux a palo seco debe ser bastante fuerte.
Menuda traducción de mierda. Voto spam, fusilarse un copy paste de Google translate no tiene esfuerzo ninguno.
#3 eso no es cierto según el artículo... "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."
#1 sí, la traducción es una mierda.
#1 Si, la traducción es una mierda, pero según mi búsqueda fueron los primeros que lo publicaron en 'castellano'.
#8 Tu búsqueda no habrá sido en Google.es no? Porque no veas cómo manipula la realidad de Internet Google, y Duckdugo v aporte el mismo camino aunque no lo parezca de momento.
Se les escucha llegar...

...a los pelacables que usan distros hipster con init (que no usa prácticamente nadie en entornos de producción) a explicarnos como systemd es el mal.
#2 Hombre, a mi en general Systemd me mola, es un poco mierda porque quiere abarcar muchas cosas a veces (en mi opinión) que por un lado te quita algunos problemas pero te da otros cuando algo no va como esperas o si algún conflicto con algo que tienes tu configurado.

Pero vamos, tampoco te diría que voy a rechazar una distro en entornos de producción porque usa "init", "openrc", "upstart" or "systemd". Aparte, que ahora hay distros ya como RancherOS que reemplazan init por Docker tal cual (rancher.com/docs/os/v1.x/en/).
#4 Systemd como tal abarca el sistema de arranque, gestión y la inicialización de la parte de usuario en el sistema. Otra cosa es que haya muchos proyectos que se alojan bajo el paraguas de systemd (por aprovechar el framework creado y reutilizar código y recursos, lo cual es la forma correcta de hacer las cosas), pero al final son muchos binarios distintos que hacen cosas muy concretas y que pueden ser sustituíbles por otros si se desarrolla algo que realice mejor la misma función.
#2 Realmente uso systemd porque "es lo que hay" pero no termina de gustarme. Me parece una complicación extra que no aporta nada notable.
#6 A nivel de usuario seguro que no, a nivel de administración de sistemas aporta muchas cosas.
#2 Systemd es el mal. Distro con OpenRC. De nada.
No se dice GNU/Linux, se dice Linux.{grin}
Obviamente hay que aclarar que antes de que se publicara esto las distribuciones han actualizado para corregirlo.
#3 Algunas aún no. En Debian aún estan explotables las dos primeras vulnerabilidades, la tercera al parecer se corrigió en el código sin que nadie se diese cuenta hace tiempo.

security-tracker.debian.org/tracker/CVE-2018-16864

security-tracker.debian.org/tracker/CVE-2018-16865

security-tracker.debian.org/tracker/CVE-2018-16866
comentarios cerrados

menéame