GNU Savannah és la forja on viuen Bash, Coreutils i centenars de projectes GNU: allotja els repositoris, els comptes dels mantenidors i les claus SSH que decideixen qui pot pujar canvis. El 30 d’octubre de 2026, Harsh Jaiswal i Rahul Maini, de l’empresa de seguretat Hacktron, van publicar com van passar d’un compte acabat de registrar a tenir a la mà l’accés d’escriptura al repositori oficial de Bash. El títol de l’article, How We Could Have Backdoored Bash, ho resumeix bé: podien fer-ho, i no ho van fer.
Una adreça de correu que executava ordres
Savannah funciona amb Savane, un programari web propi. La versió 3.17-c369, publicada el 7 de març de 2026, va introduir un camí vulnerable a la funció que comprova la clau GPG d’un usuari amb el correu del seu compte. El codi muntava una línia d’ordres amb aquesta adreça i l’executava amb proc_open(), que passa per /bin/sh. Com que el validador de correus acceptava caràcters especials de la shell, n’hi havia prou de registrar-se amb alguna cosa com a`touch${IFS}/tmp/savane-rce-proof`@attacker.example i prémer el botó de provar la clau GPG perquè el servidor executés el que hi hagués entre les cometes inverses. La ironia és que el forat era just en una eina pensada per reforçar la confiança en les signatures.
A partir d’aquí la cadena va ser curta:
- Amb una shell com a usuari del servidor web, van llegir la configuració i les credencials de la base de dades.
- Es van marcar com a superusuaris de Savannah.
- Amb l’opció de «convertir-se en aquest usuari» van entrar al compte de Chet Ramey, el mantenidor de Bash des de fa més de tres dècades, i van comprovar que la pàgina de claus SSH, la que controla qui pot fer push a
bash.git, acceptava canvis. - A part, el kernel del servidor continuava exposat a GameOver(lay) (CVE-2023-2640 i CVE-2023-32629), dues fallades d’OverlayFS amb exploit públic. Amb això van obtenir root i van trobar una clau SSH de l’usuari
gnubackupper a un servidor de còpies de seguretat de GNU.
Savannah fa servir Trisquel 11 amb un kernel linux-libre derivat del 5.15 d’Ubuntu 22.04. Canonical havia corregit GameOver(lay) el 2023 a les branques 5.19 i 6.2, però el 5.15 no va quedar marcat com a arreglat fins a l’avís USN-8255-1 del 7 de maig de 2026, quatre dies abans de l’informe d’Hacktron.
No es va tocar el repositori
Els investigadors es van aturar a la pàgina de claus. En paraules seves: «We did not add a key and we did not touch the repository» («No vam afegir cap clau i no vam tocar el repositori»). La FSF va arribar a la mateixa conclusió després de revisar controls d’accés, bases de dades i registres: no va trobar motius per pensar que s’hagués accedit a dades o credencials sensibles dels projectes «nor that there has been any compromise of Savannah’s software supply chain». Cap codi maliciós no va arribar a Bash ni a cap versió publicada. La finestra d’exposició de la fallada web va ser d’uns dos mesos, de març a maig de 2026.
Com va respondre la FSF
L’informe va arribar a la llista privada de Savannah l’11 de maig de 2026. Corwin Brust el va confirmar l’endemà i el 14 de maig la FSF va instal·lar el kernel corregit (5.15.0-177.187+11.0trisquel31) i va esborrar el compte dels investigadors. La fundació ho va tractar com un compromís complet, no com un simple pedaç d’aplicació: va revisar el sistema, va avisar l’operador d’una altra instància pública de Savane i, en lloc de corregir fallada a fallada, els voluntaris Ineiev, Corwin Brust i Bob Proulx van reescriure les parts afectades. L’arranjament de la injecció consisteix a passar el correu a GPG com un argument de dades, sense construir una cadena per a la shell.
Hacktron va continuar auditant Savane amb la seva eina assistida per IA i va reportar 26 vulnerabilitats (2 crítiques, 6 altes, 16 mitjanes i 2 baixes), entre les quals salts d’autorització a la configuració del lloc, a l’administració de llistes de correu i a l’accés a fitxers privats. La FSF va publicar una declaració el 19 de juny i el seu informe amb els pedaços el 7 d’agost. En aquest informe matisa que algunes no es van poder reproduir al sistema real i que dues de les XSS eren falsos positius, perquè l’entrada se sanejava en un altre punt del codi.
El que s’assembla a xz i el que no
Hacktron cita la porta del darrere d’xz-utils (CVE-2024-3094) com a exemple del que pot fer una sola baula compromesa. La comparació serveix, però amb matisos.
A xz, l’atacant, que signava com a Jia Tan, es va guanyar durant uns dos anys la confiança del projecte fins a ser-ne comantenidor. Les versions 5.6.0 i 5.6.1 duien la càrrega amagada en fitxers de prova del repositori i un build-to-host.m4 modificat que només era als tarballs de publicació, no a git. Com que els signava algú amb permís legítim, la signatura era vàlida. Va arribar a branques en desenvolupament de Debian, Fedora i openSUSE abans que Andres Freund ho descobrís el 29 de març de 2024 mentre investigava per què sshd trigava mig segon més.
A Bash l’accés hauria estat d’un altre tipus: una clau SSH afegida d’amagat per escriure a git, sense la clau GPG de Ramey. Un commit aliè no arriba sol als usuaris, perquè les versions de Bash surten com a tarballs signats pel mateix Ramey a ftp.gnu.org, així que el canvi s’hauria hagut d’escolar en la seva feina abans d’una publicació. És una barrera real, encara que no infal·lible: a un mantenidor que treballa amb el seu propi arbre se li pot escapar un canvi petit, i qui compila Bash des de git l’hauria rebut sense filtre. I l’accés root a Savannah i a un servidor de còpies és, per si mateix, una posició des de la qual es poden preparar atacs més pacients.
Què en pot treure un administrador
No hi ha res a actualitzar a Bash per aquest cas. Sí que hi ha hàbits que es reforcen:
- Verificar les signatures dels tarballs. Per a qualsevol paquet GNU:
gpg --verify bash-5.3.tar.gz.sig bash-5.3.tar.gz, amb la clau del mantenidor obtinguda per més d’un camí (l’anellgnu-keyring.gpg, una versió anterior ja verificada o l’empremta publicada pel projecte), no només del mateix servidor que la baixada. - Comparar el tarball amb l’etiqueta de git. La lliçó d’xz és que el que es publica pot no coincidir amb el repositori. Un
diffentre el tarball i ungit archivede l’etiqueta, descomptant el que generen les autotools, fa aflorar fitxers que no hi haurien de ser. - Recolzar-se en l’empaquetament de la distribució. Debian comprova signatures amb
uscani la clau adebian/upstream/signing-key.asc, i Fedora té la macro%gpgverifyals seus spec. El projecte Reproducible Builds permet comprovar que un binari surt de les fonts declarades. - Revisar el kernel a Ubuntu 22.04. Si alguna màquina continua amb el 5.15 sense l’USN-8255-1, GameOver(lay) continua servint a qualsevol amb una shell sense privilegis, igual que a Savannah.
- Actualitzar Savane si s’allotja una instància pròpia.
Per a qui vulgui context sobre la shell que estava en joc, a LinuxGratis repassem la història de Bash i la shell d’Unix. Savannah funciona sobre Trisquel, i els avisos del kernel 5.15 afecten Ubuntu 22.04.
Fonts: 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 a oss-security sobre xz · Wiz: GameOver(lay) · Versions de Bash a ftp.gnu.org