index.html (5571B)
1 <!DOCTYPE html> 2 <html> 3 <head> 4 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 5 <meta name="viewport" content="width=device-width, initial-scale=1" /> 6 <title>Del backdoor de SSH por xz/liblzma</title> 7 <link rel="icon" type="image/png" href="/favicon.png" /> 8 <link rel="stylesheet" type="text/css" href="../article.css" /> 9 </head> 10 <body> 11 <header> 12 <p class="title">Del backdoor de SSH por xz/liblzma</p> 13 <p class="date">1 de abril de 2024 • fjbalon</p> 14 </header> 15 <p>Como bien se sabe, este no es un blog de noticias. Ni me interesan por regla común, ni mucho menos quiero ser partícipe o servidor de ellas. Este es un blog que se centra en el mundo de las ideas, de la técnica, de lo permanente, de lo relativamente inmutable. No obstante, me gustaría hacer una noble excepción, no para producir ni informar sobre la noticia, sino para analizar la portentosa técnica que encierra.</p> 16 <p>Y me refiero a la noticia, que habréis visto en diversos foros de GNU/Linux y feudos de noticias técnicas; y no habréis visto en ningún medio de masas, del intento de backdoor en SSH a través de la biblioteca de <emb>xz/liblzma</emb>.</p> 17 <p>He considerado que la complejidad del ataque, de una precisión y técnica sobresaliente y digna de un gran intelecto, merece unas letras y un breve análisis.</p> 18 <p>La biblioteca de <emb>lzma</emb> comprometida activaría, a través de un enlace de <emb>openssh</emb>, a <emb>sd_notify</emb> (<i>systemd notify</i>) para obtener código oculto en <emb>liblzma</emb>. Así, podría crear una puerta trasera a cualquier servidor SSH de Debian/Fedora/Ubuntu.</p> 19 <p>Aparentemente, ni siquiera <emb>openssh-selinux</emb> 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 <emb>openssh.service</emb>). 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 <emb>sd_notify</emb>.</p> 20 <p>Una cosa muy llamativa es cómo gran parte de la comunidad cruzada contra systemd criticaba a <emb>zstd</emb>, defendiendo en contraposición al amigable <emb>xz</emb>. Sospechaban que el propio <emb>zstd</emb> (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 <emb>zstd</emb> se construye, mayoritariamente, con la biblioteca <emb>lzma</emb> habilitada...</p> 21 <p>«<i>Es sólo un algoritmo de compresión, no se puede usar para explotar la seguridad de un sistema, es imposible</i>» he llegado a leer por feudos del Internet. Pues este backdoor nos ha demostrado que es totalmente posible.</p> 22 <p>Buena noticia, por lo tanto, para Slackware y otras 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 <emb>openssh</emb> de cierta manera para que <emb>systemd/dbus/sd-bus/sd-notify</emb> ejecute código malicioso para obtener material de un blob de <emb>lzma</emb> para modificar los binarios en ejecución para abrir la puerta trasera. Es una genialidad, se mire por donde se mire. Y los cruzados contra systemd siguen teniendo, pues, razón.</p> 23 <p>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 <emb>xz</emb> en Github (llevado a cabo principalmente por la cuenta <i>JiaT75</i> y otras de dudosa legitimidad), para afectar como decíamos a <emb>liblzma</emb>, 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.</p> 24 <p>Pero incluso 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 demonio de SSH tardaba 500ms más de lo habitual... ¡Increible!</p> 25 26 <pre><cita> 27 After observing a few odd symptoms around liblzma (part of the xz package) on 28 Debian sid installations over the last weeks (logins with ssh taking a lot of 29 CPU, valgrind errors) I figured out the answer: 30 31 The upstream xz repository and the xz tarballs have been backdoored. 32 33 [...] 34 35 With the backdoored liblzma installed, logins via ssh become a lot slower. 36 37 time ssh nonexistant@localhost 38 39 before: 40 nonexistant@localhost: Permission denied (publickey). 41 42 before: 43 real 0m0.299s 44 user 0m0.202s 45 sys 0m0.006s 46 47 after: 48 nonexistant@localhost: Permission denied (publickey). 49 50 real 0m0.807s 51 user 0m0.202s 52 sys 0m0.006s 53 </cita></pre> 54 <anot>Fuente: <a href="https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de/">https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de/</a></anot> 55 <p>Dicen que ejecutando <emb>strings `which xz` | grep "(XZ Utils)"</emb> detectamos si contamos con una versión seguta (<<emb>5.6.0</emb>), pero sólo cerciórese en caso de cumplir los requisitos para haber sido afectado por el backdoor.</p> 56 </body> 57 </html>