Porque sostengo hace tiempo que SystemD es una reverenda mierda y no quiero adoptarlo en mis servidores GNU/Linux, y siguiendo con mi aclamada serie "SystemD y la puta madre que lo parió a el y al deficiente mental de Lennart Poettering" con sus estrafalarios errores y pelotudeces varias.
systemd da privilegios de root si el nombre de usuario comienza en un dígito
systemd can't handle the process previlege that belongs to user name startswith number, such as 0day #6237
Si un servicio se lanza con un nombre de usuario que comience con un dígito (por ejemplo "0day"), systemd no puede gestionar correctamente los privilegios y lo lanza como root.
Cabe destacar que estos son nombres de usuario válidos según el estándar POSIX.
El comentario de Lenny al respecto: "I don't think there's anything to fix in systemd here".
¿Ven el patrón de comportamiento? Esto es lo que ocurre cuando se mezcla NIH con arrogancia.
Pero lo más grotesco es ésto:
"0day no es un nombre de usuario válido". Por Dios, todas las brechas de seguridad en la historia de la seguridad informática se basan en entradas inválidas. ¿Si el nombre de usuario es invalido le doy acceso root? Por favor, acaso el mundo se está volviendo loco!? Imaginen la alarma de una casa, si la clave es inválida te dejo pasar. O una caja fuerte, si código no es válido entonces te abro la caja. Esta persona demuestra un nivel de ignorancia atroz en cuestiones de seguridad informática y es el responsable principal del desarrollo de la pieza de software más crítica en userland.
remote code execution con una respuesta DNS especialmente armada
USN-3341-1: Systemd vulnerability
Esto no tiene nada de bizarro, es un bug muy grave y con consecuencias catastróficas. Nada más y nada menos que remote code execution, esto es, poder ejecutar código arbitrario en el sistema víctima, la peor de las consecuencias ante una falla de seguridad. Sin contar con que en el menor de los casos puede provocar DoS (denial of service). El bug es provocado por systemd-resolved. ¿Por qué reimplementar dnsmasq? ¿Por qué reimplementar algo que funciona perfectamente desde hace décadas? ¿Por qué reimplementar cualquier cosa de manera tan pobre?
systemd se cuelga al setear una variable de entorno
systemd can be frozen by setting an environment variable and reexecuting after that #6152
Setear una variable de entorno y reejecutar el demonio, hace que se "freeze". ¿De qué forma una variable de entorno aleatoria puede hacer que un proceso no inicie o se congele? Y esto ocurre al tratar de "reiniciar" systemd: systemctl daemon-reexec. Estamos hablando de PID 1. ¿Ven lo que pasa cuando se jode con PID 1?
El cliente DHCP de systemd no es capaz de renovar un lease
[systemd-devel] Renew DHCP lease
Renovar un lease de DHCP debería ser una funcionalidad básica de un cliente DHCP.
Respuesta de Lenny: "This is currently not implemented."
Funcionalidades básicas no implementadas. Claramente se trata de una versión pre-alpha llevada a producción y liberada al público. Y hablando de funcionalidades no implementadas...
networkd no soporta direcciones IPv4 con máscara 31
networkd: support for /31 IPv4 addresses (rfc3021)
Este bug lleva casi un año abierto. Las direcciones IPv4 con máscara 31 (definidas en la RFC3021 de diciembre de 2000) son utilizadas comúnmente en enlaces punto a punto (point-to-point). Con máscara 31, una subred sólo puede contar con 2 direcciones IP. Al suprimir las direcciones de red y broadcast, cada una de las 2 posibles IP se utiliza como la dirección de cada uno de los puntos en el enlace. systemd desconoce esta característica del protocolo IP porque claramente es un "sistema de inicio" para notebooks.
Basado en: https://www.linuxito.com/seguridad/915-nuevos-bugs-bizarros-y-peligrosos-de-systemd
systemd da privilegios de root si el nombre de usuario comienza en un dígito
systemd can't handle the process previlege that belongs to user name startswith number, such as 0day #6237
Si un servicio se lanza con un nombre de usuario que comience con un dígito (por ejemplo "0day"), systemd no puede gestionar correctamente los privilegios y lo lanza como root.
Cabe destacar que estos son nombres de usuario válidos según el estándar POSIX.
El comentario de Lenny al respecto: "I don't think there's anything to fix in systemd here".
¿Ven el patrón de comportamiento? Esto es lo que ocurre cuando se mezcla NIH con arrogancia.
Pero lo más grotesco es ésto:
remote code execution con una respuesta DNS especialmente armada
USN-3341-1: Systemd vulnerability
Esto no tiene nada de bizarro, es un bug muy grave y con consecuencias catastróficas. Nada más y nada menos que remote code execution, esto es, poder ejecutar código arbitrario en el sistema víctima, la peor de las consecuencias ante una falla de seguridad. Sin contar con que en el menor de los casos puede provocar DoS (denial of service). El bug es provocado por systemd-resolved. ¿Por qué reimplementar dnsmasq? ¿Por qué reimplementar algo que funciona perfectamente desde hace décadas? ¿Por qué reimplementar cualquier cosa de manera tan pobre?
systemd se cuelga al setear una variable de entorno
systemd can be frozen by setting an environment variable and reexecuting after that #6152
Setear una variable de entorno y reejecutar el demonio, hace que se "freeze". ¿De qué forma una variable de entorno aleatoria puede hacer que un proceso no inicie o se congele? Y esto ocurre al tratar de "reiniciar" systemd: systemctl daemon-reexec. Estamos hablando de PID 1. ¿Ven lo que pasa cuando se jode con PID 1?
El cliente DHCP de systemd no es capaz de renovar un lease
[systemd-devel] Renew DHCP lease
Renovar un lease de DHCP debería ser una funcionalidad básica de un cliente DHCP.
Respuesta de Lenny: "This is currently not implemented."
Funcionalidades básicas no implementadas. Claramente se trata de una versión pre-alpha llevada a producción y liberada al público. Y hablando de funcionalidades no implementadas...
networkd no soporta direcciones IPv4 con máscara 31
networkd: support for /31 IPv4 addresses (rfc3021)
Este bug lleva casi un año abierto. Las direcciones IPv4 con máscara 31 (definidas en la RFC3021 de diciembre de 2000) son utilizadas comúnmente en enlaces punto a punto (point-to-point). Con máscara 31, una subred sólo puede contar con 2 direcciones IP. Al suprimir las direcciones de red y broadcast, cada una de las 2 posibles IP se utiliza como la dirección de cada uno de los puntos en el enlace. systemd desconoce esta característica del protocolo IP porque claramente es un "sistema de inicio" para notebooks.
Basado en: https://www.linuxito.com/seguridad/915-nuevos-bugs-bizarros-y-peligrosos-de-systemd
Entradas
No hay comentarios:
Publicar un comentario