# Cómo se pudo meter una puerta trasera en Bash: el fallo de GNU Savannah que encontró Hacktron - **Publicado el:** 2026-11-03 - **Categoría:** Seguridad - **Página original:** https://linuxgratis.com/articulos/hacktron-savannah-bash-cadena-suministro Una inyección de órdenes escondida en una dirección de correo dio a dos investigadores de Hacktron ejecución de código en GNU Savannah, después root y la posibilidad de añadir una clave SSH con permiso de escritura en el repositorio de Bash. No lo hicieron y no llegó código malicioso a nadie. Qué falló, cómo respondió la FSF y en qué se parece y en qué no al caso de xz. --- **GNU Savannah** es la forja donde viven Bash, Coreutils y cientos de proyectos GNU: aloja los repositorios, las cuentas de los mantenedores y las claves SSH que deciden quién puede subir cambios. El 30 de octubre de 2026, **Harsh Jaiswal y Rahul Maini**, de la empresa de seguridad **Hacktron**, publicaron cómo pasaron de una cuenta recién registrada a tener en la mano el acceso de escritura al repositorio oficial de Bash. El título del artículo, *How We Could Have Backdoored Bash*, lo resume bien: podían, y no lo hicieron. ## Una dirección de correo que ejecutaba órdenes Savannah funciona con **Savane**, un software web propio. La versión **3.17-c369, publicada el 7 de marzo de 2026**, introdujo un camino vulnerable en la función que comprueba la clave GPG de un usuario contra el correo de su cuenta. El código montaba una línea de órdenes con esa dirección y la lanzaba con `proc_open()`, que pasa por `/bin/sh`. Como el validador de correos aceptaba caracteres especiales de la shell, bastaba con registrarse con algo como ``a`touch${IFS}/tmp/savane-rce-proof`@attacker.example`` y pulsar el botón de probar la clave GPG para que el servidor ejecutara lo que hubiera entre las comillas invertidas. La ironía es que el agujero estaba justo en una herramienta pensada para reforzar la confianza en las firmas. Desde ahí la cadena fue corta: 1. Con una shell como usuario del servidor web, leyeron la configuración y las credenciales de la base de datos. 2. Se marcaron como **superusuarios** de Savannah. 3. Con la opción de «convertirse en este usuario» entraron en la cuenta de **Chet Ramey**, el mantenedor de Bash desde hace más de tres décadas, y comprobaron que la página de claves SSH, la que controla quién puede hacer *push* a `bash.git`, aceptaba cambios. 4. Por separado, el kernel del servidor seguía expuesto a **GameOver(lay)** (CVE-2023-2640 y CVE-2023-32629), dos fallos de OverlayFS con exploit público. Con él obtuvieron **root** y encontraron una clave SSH del usuario `gnubackup` para un servidor de copias de seguridad de GNU. Savannah usa **Trisquel 11** con un kernel linux-libre derivado del 5.15 de Ubuntu 22.04. Canonical había corregido GameOver(lay) en 2023 en las ramas 5.19 y 6.2, pero el 5.15 no quedó marcado como arreglado hasta el aviso USN-8255-1 del **7 de mayo de 2026**, cuatro días antes del informe de Hacktron. ## No se tocó el repositorio Los investigadores se pararon en la página de claves. En sus palabras: «*We did not add a key and we did not touch the repository*» («No añadimos ninguna clave y no tocamos el repositorio»). La FSF llegó a la misma conclusión tras revisar controles de acceso, bases de datos y registros: no encontró motivos para pensar que se accediera a datos o credenciales sensibles de los proyectos «*nor that there has been any compromise of Savannah's software supply chain*». **Ningún código malicioso llegó a Bash ni a ninguna versión publicada.** La ventana de exposición del fallo web fue de unos dos meses, de marzo a mayo de 2026. ## Cómo respondió la FSF El informe llegó a la lista privada de Savannah el **11 de mayo de 2026**. Corwin Brust lo confirmó al día siguiente y el **14 de mayo** la FSF instaló el kernel corregido (5.15.0-177.187+11.0trisquel31) y borró la cuenta de los investigadores. La fundación lo trató como un compromiso completo, no como un simple parche de aplicación: revisó el sistema, avisó al operador de otra instancia pública de Savane y, en lugar de corregir fallo a fallo, los voluntarios Ineiev, Corwin Brust y Bob Proulx reescribieron las partes afectadas. El arreglo de la inyección consiste en pasar el correo a GPG como un argumento de datos, sin construir una cadena para la shell. Hacktron siguió auditando Savane con su herramienta asistida por IA y reportó **26 vulnerabilidades** (2 críticas, 6 altas, 16 medias y 2 bajas), entre ellas saltos de autorización en la configuración del sitio, en la administración de listas de correo y en el acceso a ficheros privados. La FSF publicó una declaración el 19 de junio y su informe con los parches el **7 de agosto**. En ese informe matiza que algunas no se pudieron reproducir en el sistema real y que dos de las XSS eran falsos positivos, porque la entrada se saneaba en otro punto del código. ## Lo que se parece a xz y lo que no Hacktron cita la puerta trasera de **xz-utils** (CVE-2024-3094) como ejemplo de lo que puede hacer un solo eslabón comprometido. La comparación sirve, pero con matices. En xz, el atacante, que firmaba como Jia Tan, se ganó durante unos dos años la confianza del proyecto hasta ser comaintenedor. Las versiones 5.6.0 y 5.6.1 llevaban la carga escondida en ficheros de prueba del repositorio y un `build-to-host.m4` modificado **que solo estaba en los tarballs de publicación**, no en git. Como los firmaba alguien con permiso legítimo, la firma era válida. Llegó a ramas en desarrollo de Debian, Fedora y openSUSE antes de que **Andres Freund** lo descubriera el 29 de marzo de 2024 al investigar por qué `sshd` tardaba medio segundo más. En Bash el acceso habría sido de otro tipo: una clave SSH añadida a escondidas para escribir en git, sin la clave GPG de Ramey. Un commit ajeno no llega solo a los usuarios, porque las versiones de Bash salen como **tarballs firmados por el propio Ramey** en ftp.gnu.org, así que el cambio habría tenido que colarse en su trabajo antes de una publicación. Es una barrera real, aunque no infalible: a un mantenedor que trabaja con su propio árbol se le puede escapar un cambio pequeño, y quien compila Bash desde git lo habría recibido sin filtro. Y el acceso root a Savannah y a un servidor de copias es, por sí mismo, una posición desde la que se pueden preparar ataques más pacientes. ## Qué puede sacar de aquí un administrador No hay nada que actualizar en Bash por este caso. Sí hay hábitos que se refuerzan: - **Verificar las firmas de los tarballs.** Para cualquier paquete GNU: `gpg --verify bash-5.3.tar.gz.sig bash-5.3.tar.gz`, con la clave del mantenedor obtenida por más de un camino (el anillo `gnu-keyring.gpg`, una versión anterior ya verificada o la huella publicada por el proyecto), no solo del mismo servidor que la descarga. - **Comparar el tarball con la etiqueta de git.** La lección de xz es que lo publicado puede no coincidir con el repositorio. Un `diff` entre el tarball y un `git archive` de la etiqueta, descontando lo que generan autotools, saca a la luz ficheros que no deberían estar. - **Apoyarse en el empaquetado de la distribución.** Debian comprueba firmas con `uscan` y la clave en `debian/upstream/signing-key.asc`, y Fedora tiene la macro `%gpgverify` en sus spec. El proyecto Reproducible Builds permite comprobar que un binario sale de las fuentes declaradas. - **Revisar el kernel en Ubuntu 22.04.** Si alguna máquina sigue con el 5.15 sin el USN-8255-1, GameOver(lay) le sigue sirviendo a cualquiera con una shell sin privilegios, igual que en Savannah. - **Actualizar Savane** si se aloja una instancia propia. Para quien quiera contexto sobre la shell que estuvo en juego, en LinuxGratis repasamos la [historia de Bash y la shell de Unix](/articulos/historia-de-bash-shell). Savannah corre sobre [Trisquel](/trisquel), y los avisos del kernel 5.15 afectan a [Ubuntu](/ubuntu) 22.04. **Fuentes:** [Hacktron: Securing Internet-Critical Software: How We Could Have Backdoored Bash](https://www.hacktron.ai/blog/hacking-gnu-savannah) · [FSF: Statement regarding GNU Savannah security reports](https://www.fsf.org/news/statement-regarding-gnu-savannah-security-reports) · [FSF: Update on GNU Savannah security issue (PDF)](https://static.fsf.org/nosvn/security/savannah-20260807.pdf) · [Andres Freund en oss-security sobre xz](https://www.openwall.com/lists/oss-security/2024/03/29/4) · [Wiz: GameOver(lay)](https://www.wiz.io/blog/ubuntu-overlayfs-vulnerability) · [Versiones de Bash en ftp.gnu.org](https://ftp.gnu.org/gnu/bash/)