Seré breve, puesto que acaba de subirse el vídeo.
¿Que opinan?
Ya que toca el famoso caso de xz-utils.
4 Me gusta
Ese video acabó siendo un buen video en promoción del software libre, puesto que pone como idiotas a los desarrolladores de software privativo, pues aceptan acuerdos de confidencialidad, como las licencias de software que no es libre.
Lamentablemente durante todo el video hablan de gratuidad cuando en ninguna de las ocasiones va al caso, pues GNU con Linux y todo el resto, no tienen interés en la gratuidad.
Pero de resto, interesante.
1 me gusta
Me chafó el tema que llevaba preparando algún tiempo 
(El vídeo es genial. Es LinuxChad si generara millones de dólares.)
7 Me gusta
Todavía nadie habla John Gilmore, y de su importante influencia, la barrera del idioma aún sigue siendo un problema para muchos.
Amo el canal Veritasium en Español pero LinuxChad es mejor.
1 me gusta
Chicle y pega, me han tocado ver vídeos del mismo tema, me gusta, pero depende como lo tomes o lo puedas narrar, me gusta mucho por que lo haces muy sencillo, fácil de aprender, pero si no crees que pegue, creo deberías cambiar la forma en que lo miras.
1 me gusta
Me encanta la manera en que cuenta la historia, creo que explicaron todo muy bien incluso una persona que no sabe mucho del tema puede entender la gravedad del asunto. Me dio mucha alegría ver este video.
1 me gusta
no llevo ni la mitad y es simplemente hermoso
El vídeo está muy bien. Muy original el ejemplo de las pinturas para «desabstraer» el funcionamiento de la criptografía asimétrica, RSA concretamente.
En cuanto a la vulnerabilidad del backdoor en SSH por xz/liblzma, por profundizar más:
La biblioteca de lzma comprometida activaría a través de un enlace de openssh a sd_notify (systemd notify) para obtener código oculto en liblzma para crear una puerta trasera a cualquier servidor SSH de Debian/Fedora/Ubuntu. Aparentemente, ni siquiera openssh-selinux sería seguro en esas condiciones (glibc, x86-64, fuente de tarball preconfigurada de github 5.6.0 y 5.6.1, systemd empaquetado, openssh, rpm o deb, con llamadas habilitadas a systemd a través de openssh.service). Si la fuente se creó a partir de git con autoconf/make limpio nativo, el código malicioso no se habría incluido. Los sistemas musl (Alpine, Gentoo, OpenWRT o Void) no tienen nada de qué preocuparse, simplemente porque ni siquiera pueden compilar sd_notify para activar todo esto.
Es muy llamativo porque gran parte de la comunidad de la cruzada contra systemd criticaba a zstd, defendiendo en contraposición al amigable xz. Sospechaban que el propio zstd (o Zstandard, que para quien no lo conozca, es un algoritmo de compresión desarrollado por Facebook para Linux), tenía el riesgo de ser un caballo de Troya para la seguridad y el cifrado, siendo que incluso zstd se construye, mayoritariamente, con la biblioteca lzma habilitada…
«Es sólo un algoritmo de compresión, no se puede usar para explotar la seguridad de un sistema, es imposible» he llegado a leer por feudos del Internet. Pues este backdoor nos ha demostrado que es totalmente posible.
Buena noticia para Slackware y distros no-systemd: hasta donde los expertos en Debian, Fedora, Arch o Ubuntu han llegado, se necesita necesariamente systemd para ‘energizar’ la puerta trasera, específicamente un gancho utilizado por Debian para construir openssh de cierta manera para que systemd/dbus/sd-bus/sd-notify ejecute código malicioso para obtener material de un blob de lzma para modificar los binarios en ejecución para abrir la puerta trasera. Es una genialidad, se mire por donde se mire.
Este complejísimo ataque sobre librerías y códigos abiertos -apertura que permite a la comunidad, o a cualquiera que entienda, monitorizar los commits y evolución del código- ha llevado prácticamente 2 años a través de la librería xz en github (llevado a cabo principalmente por la cuenta JiaT75 1 y otras de dudosa legitimidad), para afectar como decíamos a liblzma, el vector de ataque. Tenga en cuenta el lector, que esta gran complejidad para insertar un backdoor es precisamente por la naturaleza del código abierto, en código cerrado probablemente otro gallo cantaría, incluso para la detección.
Y la detección tiene tela. Andres Freund, un trabajador de Microsoft (valga el chiste, salvados por Microsoft, xd) mientras realizaba tests de rendimiento notó que el daemon de SSH tardaba 500ms más de lo habitual… ¡Increible!
After observing a few odd symptoms around liblzma (part of the xz package) on
Debian sid installations over the last weeks (logins with ssh taking a lot of
CPU, valgrind errors) I figured out the answer:
The upstream xz repository and the xz tarballs have been backdoored.
[...]
With the backdoored liblzma installed, logins via ssh become a lot slower.
time ssh nonexistant@localhost
before:
nonexistant@localhost: Permission denied (publickey).
before:
real 0m0.299s
user 0m0.202s
sys 0m0.006s
after:
nonexistant@localhost: Permission denied (publickey).
real 0m0.807s
user 0m0.202s
sys 0m0.006s
Fuente: https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de/
Dicen que ejecutando strings which xz | grep "(XZ Utils)" detectamos si contamos con una versión segura (<5.6.0), pero sólo cerciórese en caso de cumplir los requisitos para haber sido afectado por el backdoor.
2 Me gusta
A mi no, el ejemplo me confundió más. Prefiero entenderlo literal que con ejemplos. Así aprendí en física, cuando me dan ejemplos termino entendiendo mal y resuelvo mal los problemas.
1 me gusta
yo soy un poco alrevez, me imagino el ejemplo en mi cabeza con una metafora o situación inventada y asi lo estructuro mejor