Cómo se pudo meter una puerta trasera en Bash: el fallo de GNU Savannah que encontró Hacktron

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. Savannah corre sobre Trisquel, y los avisos del kernel 5.15 afectan a Ubuntu 22.04.

Fuentes: Hacktron: Securing Internet-Critical Software: How We Could Have Backdoored Bash · FSF: Statement regarding GNU Savannah security reports · FSF: Update on GNU Savannah security issue (PDF) · Andres Freund en oss-security sobre xz · Wiz: GameOver(lay) · Versiones de Bash en ftp.gnu.org