robertdfrench/ifuncd-upGNU IFUNC es el verdadero culpable detrás de CVE-2024-3094
Veo que ustedes, bromistas de [el sitio naranja][hn], me están dando duro. Haré algunas respuestas selectas a continuación, pero primero ofrezco un desafío: enviaré $500 de mi propio dinero a la primera persona que pueda demostrar este ataque sin ifunc. Estoy genuinamente interesado, y dispuesto a pagar por la iluminación. Haz un fork de este repo y envía un PR con tu PoC funcional, solicitaré tu dirección postal en privado si ganas. Ahora las respuestas:
Esto está ladrando al árbol equivocado.
Chico, yo vivo en el árbol equivocado, puedo ladrarle a quien quiera.
No era esencial para el exploit,
¡Tú no eres esencial para el exploit!
Siempre está selinux si queremos añadir protección contra código arbitrario ejecutándose como root.
Una vez cargado, este ataque no necesitaba cruzar más fronteras de syscalls. Así que sí, podríamos haber restringido una sesión root "de bonificación", ¡pero todavía habríamos tenido invitados no invitados en la máquina!
¿Qué es esto, el cumpleaños de Bilbo? ¡¡Sin entrada excepto para asuntos de la fiesta!!
- IFUNC apenas es la única forma de ejecutar código antes de main.
Pero es una forma innecesaria de ejecutar código antes de que se configure la protección de memoria
- La alternativa que presentan es posiblemente menos segura porque el puntero de función permanecerá escribible durante toda la vida del proceso,
¡Podemos improvisar con mprotect! Véase la última frase antes de la subsección Modifying LD_PRELOAD.
Sí, este blog está equivocado.
Disculpe, este blog estaba sin guía. ¡Hice todas estas travesuras yo mismo! Nadie me engañó para ser así de estúpido.
IFUNC debería ser implementado por el propio software [cliente],
@CountWSS 💯 claro que sí
una serie de fallos flagrantes de proceso por parte del mantenedor de Github a través de ...
Este es el único punto al que responderé en serio:
Creo que es extraordinariamente injusto con el mantenedor de xz-utils y bastante peligroso para la comunidad pensar en esto como comenzando con un error por su parte. Comenzó con que a nadie le importaba una mierda ayudar a mantener este proyecto. El atacante dependió de ifunc como una vulnerabilidad técnica y de nuestra negligencia colectiva de xz-utils como una vulnerabilidad social. Creo que es vergonzoso ver las acciones del Sr. Collin como algo distinto de una dedicación heroica de años al servicio de la comunidad.
Además Bruce Schneier está de acuerdo conmigo así que... lo siento por ti, tu argumento está muerto.
El lenguaje puede haber sido más duro de lo necesario
No vas a creer cuánto me hicieron suavizar esto mis amigos primero.
Las distribuciones de Linux no deberían tenerse en tan alta estima como para esperar que OpenBSD se conforme y se adapte a su desastre
@debazel!!! Me gusta.
Qué completa mierda de caballo.
Vale, esa parte es precisa.
Por qué deberías dejar de culpar a xz-utils por [CVE-2024-3094][nvd]. También ¡echa un vistazo a mi ETSA Talk!
CVE-2024-3094, más comúnmente conocido como "El backdoor de xz-utils", fue un casi accidente para la ciberseguridad global. Si este ataque no hubiera sido descubierto justo a tiempo por [Andres Freund][freund], la mayoría de los servidores SSH de nuestro planeta habrían comenzado a otorgar acceso root a la parte detrás de este ataque.
Desafortunadamente, demasiado análisis se ha centrado en cómo [código malicioso][JiaT75] llegó al repositorio de xz-utils. En cambio, me gustaría argumentar que dos decisiones de diseño de larga data en software de código abierto crítico son lo que hicieron posible este ataque: [enlazar OpenSSH contra SystemD][biebl], y la existencia de [GNU IFUNC][sourceware].
Antes de empezar: Gran parte de esta discusión trata las complejidades
del enlazado dinámico en Linux. Si necesitas un repaso, consulta
dynamic_linking.md.
Hay toneladas de buenos artículos que describen los detalles de alto nivel del backdoor de xz-utils, como [What we know about the xz Utils backdoor that almost infected the world][goodin1] de Dan Goodin y el gist [FAQ on the xz-utils backdoor (CVE-2024-3094)][thesamesam] de Sam James. No necesitamos repetir todo eso aquí, así que para los propósitos de este artículo, aquí hay un repaso muy general:
## ¿Por qué las distribuciones de Linux modifican OpenSSH?
La respuesta corta es que tienen que hacerlo. OpenSSH es desarrollado por
la comunidad de OpenBSD, para la comunidad de OpenBSD, y no les importa
lo más mínimo Linux. El proyecto [Portable OpenSSH][mindrot] es una
recopilación de parches hecha con el mejor esfuerzo posible que reemplaza
los componentes específicos de OpenBSD con componentes POSIX genéricos, y
algo de código específico de plataforma cuando corresponde. La cadena de
suministro de software para SSH termina pareciéndose en la práctica a
algo así:```mermaid
flowchart TD
subgraph OpenBSD Folks
A[OpenBSD]
B[OpenSSH]
H[improvements]
end
B-->A
A-->H
H-->B
B-->C
C[Portable OpenSSH]
subgraph Debian Folks
D[Debian SSH]
G[improvements]
end
C-->D
D-->G
G-->C
subgraph Fedora Folks
J[Fedora SSH]
K[improvements]
end
C-->J
J-->K
K-->C
La versión de OpenSSH de OpenBSD es upstream respecto a todo lo demás, y la mayoría de las mejoras provienen de dentro de la comunidad de OpenBSD. Estos cambios fluyen downstream hacia el proyecto Portable OpenSSH, que intenta reimplementar nuevas funcionalidades de formas que no sean específicas de OpenBSD. Esto es lo que permite que SSH funcione en plataformas como Linux, macOS, FreeBSD e incluso Windows.
Pero no se detiene ahí. Algunos sistemas operativos aplican una personalización adicional más allá de lo que proporciona Portable OpenSSH. Por ejemplo, Apple añade el flag [--apple-use-keychain][keith] a ssh-add para ayudarlo a integrarse con el gestor de contraseñas de macOS.
En el caso de CVE-2024-3094, Fedora y Debian mantenían sus propios [parches de SystemD][biebl] para sus forks de OpenSSH con el fin de corregir una [condición de carrera en los reinicios de sshd][schmidt]. Así que la cadena de suministro real de SSH empezó a verse así:```mermaid
flowchart TD
A[OpenSSH]
B[Portable OpenSSH]
C[Debian SSH]
D[Fedora SSH]
A-->B
B-->C
B-->D
C<-->|SystemD Patches|D
Estos parches nunca llegaron a Portable OpenSSH, porque la gente de
Portable OpenSSH ["no estaba interesada en tomar una dependencia de
libsystemd"][djmdjm]. Y nunca llegaron a OpenSSH upstream, porque
OpenBSD no tiene ninguna necesidad de soportar SystemD.