Se ha incrustado una vulnerabilidad tipo "backdoor" (que permitiría un acceso al sistema infectado) en las últimas versiones de la librería de compresión liblzma, que es usada por las grandes distros de GNU/Linux en el paquete OpenSSH, que proporciona acceso a equipos remotos. Enlace al anuncio del desarrollador que ha encontrado la puerta trasera. Más info en el enlace.
|
etiquetas: xz , xzbackdoor , liblzma , ssh , openssh , backdoor , vulnerabilidad
tukaani.org/xz-backdoor/
En Debian están proponiendo ya eliminar completamente el paquete xz-utils y hacer una transición dura hacia ZSTD
xz 5.2.4-2
En Slackware 15 (la current supongo que se lo habrá comido) será similar.
Slackware -stable con slapt-get y algunos repos (slapt-get maneja deps y prioridades) puede ser tan capaz como Arch pero siendo LTS.
Hay un repo que tiene compilados todos los paquetes de Slackbuilds.
En Ubuntu, la versión más nueva en 23.10 era la 5.4.1 (Mantic Minotaur), pero estaba la 5.6 en la que sale en abril, 24.04 (Noble Numbat), y ahora sale con el mismo fix… » ver todo el comentario
"openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma."
El problema es de Systemd aunque lo que se ve afectado es OpenSSH. De un parche que muchas distros añaden para que OpenSSH funcione con el sistema de notificaciones de Systemd.
* www.openwall.com/lists/oss-security/2024/03/29/4
objdump -x $(which ssh) | grep NEEDED:
termbin.com/f71c
No es lo mismo firmado que autenticado. Sí puedes añadir cosas a un repo sin ningún permiso, otra cosa es que necesites autenticarte para hacer pull a una plataforma como GitHub.
Pero yo no hablo de eso, sino de la firma del commit, que es algo propio de git (no como la autenticación de plataformas remotas, aunque soportado por todas ellas). Git te permite firmar los commits (GPG, s/mime...), pero no todo el mundo lo hace. Y éste es uno de esos casos.
* XZ Utils 5.6.0 and 5.6.1 release tarballs contain a backdoor. These tarballs were created and signed by Jia Tan.
* Tarballs created by Jia Tan were signed by him. Any tarballs signed by me were created by me.
De los commits no dice nada, pero se asume que si alguien se hace con el control de la cuenta de un desarrollador, potencialmente podría subir y firmar lo que quiera.
se asume que si alguien se hace con el control de la cuenta de un desarrollador, potencialmente podría subir y firmar lo que quiera
No tiene por qué. Te pueden comprometer la cuenta de GitHub pero no tener acceso a tu passphrase de GPG, de hecho hay que ser muy insensato para almacenarla en un lugar que no sea la mente de uno
Pero bueno, te podría contar historias de miedo de gente que guarda todas sus contraseñas en un txt en el escritorio o que reutiliza contraseñas y extrayéndo las del navegador (harto sencillo) te haces con todas las llaves.
Y por supuesto en un fichero que se llama "contraseñas.txt"
Trabajo en ciberseguridad y no te puedes ni imaginar la cantidad de casos de esos que se encuentran en medio de muchos incidentes. Incluso de algunos bastante sonados... Empresas que gastan un pastizal en seguridad para que luego "alguien" anote en un txt las credenciales ssh de un túnel que "alguien" abrió contra el entorno de desarrollo desde el cual, misteriosamente, se llega al entorno de producción... La verdad es que poco pasa.
De hecho, hace años, la única manera de convencer a una empresa de que eliminase la clave privada de la CA root que tenían almacenada en su servidor de ficheros fue proponiéndoles escribirla en dos papeles, dividirlos a la mitad y guardarlos en cuatro lugares bajo llave distintos
ahí meten hasta los CCC de sus bancos.
Si es que el mundo sigue rodando por la inercia que lleva...
Luego en la interfaz de GitHub los commits saldrían con el tick verde indicando que están firmados y nadie se daría cuenta.
En absoluto. La claves privadas no se almacenan en la cuenta de GitHub, sólo las públicas.
Pero eso no es una particularidad de GitHub, es la base misma de la criptografía asimétrica. Almacenar la clave privada en el sitio que tiene que verificarla sería peor incluso que no firmar nada.
docs.github.com/en/authentication/managing-commit-signature-verificati
You can add multiple public keys to your account on GitHub. Commits signed by any of the corresponding private keys will show as verified.
Claves públicas. Lo que no puedes añadir son claves privadas, ni por tanto cambiarlas por otras.
Podrías añadir claves públicas, pero sería obvio para cualquiera que no es la misma firma.
Tú me estás contando cosas de claves privadas, y públicas mientras que yo te hablo del caso específico de GitHub y su interfaz.
Tú me estás contando cosas de claves privadas, y públicas
Lo que te estoy contando es que no puede subir claves privadas a GitHub, por más que te empeñes en repetirlo.
> Lo que te estoy contando es que no puede subir claves privadas a GitHub, por más que te empeñes en repetirlo.
No me empeño en nada porque no lo he dicho nunca. Se puede cambiar la clave privada como ya te he explicado un par de veces pero eso no quiere decir que la subas a GitHub.
La clave privada, el passphrase en este caso, idealmente no debería estar almacenada más que en tu cabeza, ya que es lo que te permite a ti (y quien la tenga) firmar en tu nombre.
Lo cierto es que no era sencillo de detectar, estaba muy bien ofuscado entre los tests.
De hecho, en el comunicado oficial se afirma que los commits estaban firmados, pero no es cierto.
github.com/google/oss-fuzz/pull/10667
¿Será de la CIA el colega este? (o cualquier otro servicio secreto)
Igual nos llevamos una sorpresa.
Me extrañó una actualización de solo dos componentes, suele pasar con los navegadores, pero no con utilidades.
Aquí un resumen de lo que se va encontrando boehs.org/node/everything-i-know-about-the-xz-backdoor
Me parece una historia super interesante.
Probablemente un proyecto de espionaje a largo plazo de algún gobierno.
lcamtuf.substack.com/p/technologist-vs-spy-the-xz-backdoor
Uso esta distro en vez de Windouze de Micro$oft, porque nunca está expuesta a vulnerabilidades y tiene todos todos los programas que necesito.
¿Soluciones? Congelar el desarrollo de algunos productos cuando llegan a cierta versión, auditar bien el código por parte de diversas organizaciones y luego no empeñarse en usar la ultimísima versión, sino una versión congelada. Si una versión cumple con una determinada funcionalidad se puede usar sin problema. ¿Que intentan colar un fallo en el código? Cuando se haga la próxima congelación se podría ver al auditar el código.
Muy naif eso q dices....
Tu como crees q funcionan Pegasus y compañia?
A ese le han PAGADO durante 2 años para meter eso ahi.
Alguna empresa de defensa o algun pais. Y por el nombre de usuario apostaria a que NO era chino.
Apuesto por Israel o USA. O Rusia tal vez...
No en serio. Para mi es igual de grave que si lo mete en Windows o en Macos.
Si lo lleva a ofuscar mejor, nos lo comemos con patatas