Ceph pedaça quatre CVE: tres els tanca el paquet i el quart el tanques tu

Ahir dimecres el projecte Ceph va publicar dues versions amb un títol que no es veu cada any: «[CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released». Quatre CVE de cop. I, a l'apartat de passos crítics, una frase que li canvia la setmana a molta gent: CephX estrena tipus de clau. És el primer cop que passa.

La recomanació del projecte és la de sempre i és la correcta: «We strongly recommend that all Ceph operators upgrade to one of these releases as soon as possible». Però convé llegir el que ve darrere, perquè de les quatre fallades, tres se'n van amb el paquet i una no. La quarta se'n va quan algú hagi rotat, una per una, totes les claus del clúster. Això no cap en una finestra de manteniment de mitja hora.

Els quatre, en una taula

Els quatre figuren com a High a l'índex de vulnerabilitats del mateix projecte, i els quatre comencen igual a «versions afectades»: all prior versions. No hi ha cap branca antiga fora de perill. Convé mirar sota aquesta etiqueta, perquè el desglossament CVSS de cada fitxa no coincideix: els quatre són High en confidencialitat, però només dos ho són també en integritat. I els dos d'RGW només t'afecten si tens passarel·la S3.

Una clau de només lectura i tot el clauer

El CVE-2026-50152 és el que fa més angúnia de llegir. La descripció de Ceph no deixa marge a la interpretació: «Any CephX user holding mon allow r caps can read the entire Monitor config-key store by sending a single crafted MMonSubscribe message». Un missatge. Sense condicions addicionals.

L'interessant és què s'hi guarda a dins, i també ho diu la fitxa: «This includes OSD LUKS passphrases and, on cephadm-managed clusters, the SSH private key cephadm uses to authenticate on every Ceph host». El desglossament d'impacte ho remata: «An attacker can exfiltrate the entire cluster secret store, including dm-crypt keys, dashboard secrets, and gateway credentials».

La lectura és nostra, però costa poc de fer: mon allow r és el permís mínim amb què surt qualsevol client. Cada node que munta un RBD el té, i cada client de CephFS també. Si has xifrat els OSD en repòs —el que es demana així que hi ha dades sensibles a sobre— la passphrase que obre aquests discos vivia al mateix magatzem que aquell client podia llegir d'una tirada, o sigui que el disc continuava xifrat i la clau era a la vista de mig clúster.

El paquet tanca la lectura. El que el paquet no pot fer és canviar els secrets que hi porten des que vas muntar el clúster. I aquí Ceph és honest fins al punt de resultar inquietant: «Formal guidance on rotating all secrets stored in the Monitor config-key store will be forthcoming». Ara mateix només hi ha procediment establert per a un, la clau SSH de cephadm. Per a la resta, la recomanació literal és que cada operador «assess their cluster's potential exposure».

El de CephX repeteix un error del 2004

El CVE-2025-30156 és el gros, i el seu diagnòstic es llegeix gairebé com una confessió: «CephX's AES-128-CBC encryption is unauthenticated. It has no HMAC, and it uses a hard-coded initialization vector. This is the same weakness MIT documented in Kerberos 4 in the 2004 PERILS paper». L'IV fix fa que dos textos iguals xifrin igual, cosa que ja és lletja. El més greu és la manca d'autenticació: es poden invertir bits del text xifrat, canviar el que hi ha a sota, i res no ho detecta.

Hi ha un camí llarg, criptogràficament entretingut, en què l'atacant actua com a oracle de xifratge creant identitats amb noms a mida per recollir blocs. I hi ha un camí curt, que és el que espanta: «one can simply perform a CBC bitflip on the allow_all field of the encrypted AuthTicket structure, gaining admin privileges for the OSD, MDS, and MGR services». David Mohren, de CLYSO, té una prova de concepte demostrada que arriba a administrador del clúster.

La solució es diu aes256k: AES256-CTS-HMAC-SHA384-192, l'esquema de l'RFC 8009 que fa servir Kerberos 5. Confusor aleatori de 128 bits a cada operació, HMAC-SHA384 per detectar manipulació, i robatori de text xifrat per no necessitar farciment. La llista de crèdits també mereix una línia: ho va notificar Erin Shepherd, d'e43.eu, i després de manera independent David Mohren i Mark Nelson, de CLYSO; i també ho va notificar i validar David Korczynski, d'Ada Logics, perquè ho va trobar Anthropic «using agents to study the security of open-source projects».

Per què instal·lar no n'hi ha prou per a aquest

Perquè les claus que ja existeixen continuen sent de tipus aes. El binari nou entén el tipus nou, però no reescriu les credencials que tens: manté compatibilitat cap enrere a propòsit, perquè el clúster no caigui en actualitzar. El que fa és començar a queixar-se, amb sis comprovacions de salut que la mateixa documentació t'avisa que apareixeran: AUTH_INSECURE_KEYS_CREATABLE, AUTH_INSECURE_KEYS_ALLOWED, AUTH_INSECURE_SERVICE_KEY_TYPE, AUTH_INSECURE_SERVICE_TICKETS, AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE i AUTH_INSECURE_CLIENT_KEY_TYPE.

Dues d'aquestes sis no són avisos, són errors. ceph health detail les treu amb [ERR]: AUTH_INSECURE_SERVICE_TICKETS i AUTH_INSECURE_SERVICE_KEY_TYPE. Traduït al que veu la teva monitorització: el clúster es queda en HEALTH_ERR des que actualitzes fins que acabes de rotar, que poden ser setmanes. Convé saber-ho abans que soni el telèfon a les tres de la matinada, i convé dir-ho a qui estigui de guàrdia.

Deu passos, i l'ordre importa

El procediment que Ceph ha afegit a la referència de configuració de CephX té deu passos numerats. Un d'ells, el sisè, el desaconsella la mateixa documentació per a la majoria de desplegaments. Aquest n'és el resum, amb les ordres que importen:

1. Permetre el tipus nou. En clústers actualitzats ho fan els monitors sols; es comprova mirant el camp auth_allowed_ciphers a la sortida de ceph mon dump, on ha d'aparèixer aes,aes256k.
2. Canviar el tipus per defecte per a claus noves: ceph mon set auth_preferred_cipher aes256k. Te'l pots saltar a propòsit si encara hi ha aplicacions client que no l'entenen.
3. Rotar les claus de tots els dimonis: mon. primer, després mgr, osd i mds, un a un, aturant el dimoni abans. Desa el mon.keyring que surt de la primera ordre: si un monitor estava fora de quòrum durant la rotació, no tindrà la clau nova i caldrà posar-l'hi a mà.
4. Comprovar que l'avís ha desaparegut: ceph health detail ja no ha de llistar AUTH_INSECURE_SERVICE_KEY_TYPE. Si encara hi és, queda algun dimoni sense rotar.
5. Pujar el xifratge dels tiquets rotatius: ceph mon set auth_service_cipher aes256k.
6. Esborrar els tiquets rotatius vells amb ceph auth wipe-rotating-service-keys. Aquí la documentació diu literalment «This is not recommended for most deployments»: val més deixar que caduquin sols en unes hores.
7. Impedir que es creïn claus insegures noves: ceph config set mon 'mon auth allow insecure key' false.
8. Rotar client.admin. Abans, crear una clau de rescat (client.admin-backup) i comprovar que funciona. Si t'equivoques aquí sense xarxa, la recuperació és llarga.
9. Rotar la resta de claus de client, i copiar cadascuna a cada màquina que la fa servir. ceph health detail te les llista pel nom.
10. Prohibir el tipus vell: ceph mon set auth_allowed_ciphers aes256k. I aquí l'avís més seriós del document: fes-ho amb una sola clau sense rotar i et quedes fora del clúster, amb rescat per «Emergency Allowed Ciphers».

Hi ha una vàlvula d'escapament reconeguda a la mateixa documentació, i agraïm que hi sigui: si encara no pots rotar una clau de client concreta, es pot silenciar l'avís amb ceph health mute AUTH_INSECURE_CLIENT_KEY_TYPE 8w. Vuit setmanes. El text que acompanya l'ordre diu «We expect this to be typical situation for some clusters», que és una manera elegant d'admetre que això durarà mesos en instal·lacions grans.

Vam anar a mirar el repositori de Proxmox

Bona part dels clústers Ceph que veiem a Espanya els instal·la Proxmox VE, des dels repositoris que manté Proxmox. Així que aquesta tarda, abans d'escriure res, vam anar a mirar què hi ha publicat. L'ordre cap en una línia:

curl -s http://download.proxmox.com/debian/ceph-squid/dists/trixie/\
no-subscription/binary-amd64/Packages.gz | gunzip \
  | awk '/^Package: ceph-common$/{p=1} p&&/^Version:/{print;p=0}'

L'última versió que retorna, avui 20 d'agost a les 13:40, és 19.2.5-pve2. A la branca Tentacle, 20.2.2-pve1. A bookworm, per a qui continuï a Proxmox VE 8, 19.2.5-1~bpo12+2. Els índexs no s'han tocat des del 27 de juliol (Squid a trixie), el 29 de juliol (Squid a bookworm) i el 7 de juliol (Tentacle). Cap de les versions pedaçades no hi és.

No és cap retret: empaquetar una release de Ceph amb la serietat amb què ho fa Proxmox porta el seu temps, i l'avís té menys de vint-i-quatre hores. És una dada que canvia el pla d'aquesta setmana, perquè si el teu Ceph l'instal·la Proxmox, avui no hi ha res per instal·lar i sí força per preparar. I perquè convé tenir el reflex de mirar el repositori en comptes de refiar-se que un apt upgrade porti el que creus que porta — és el mateix reflex que cal amb les dates de fi de suport.

Hi ha una segona conseqüència, i aquesta és la que pesa. La nota de Ceph diu que «deployments using cephadm will automate the process except for client keys». Proxmox gestiona els dimonis de Ceph ell mateix, sense cephadm. L'automatització, que en cephadm cobreix tot menys les claus de client, aquí no serveix: en un clúster hiperconvergit de Proxmox la rotació és a mà, sencera, monitor per monitor i OSD per OSD.

El kernel, que aquí sí que acompanya

El client Ceph del kernel —el que fan servir krbd i els muntatges de CephFS— també ha d'entendre aes256k, encara que Ceph matisa que les actualitzacions de client i kernel «are recommended to support the new key type but not required to resolve the most serious aspects of the security vulnerability». Sobre quin kernel cal, és concret: «Linux kernel support began in 7.0 and has been backported to CentOS Stream 9 and 10». Proxmox VE 9 va amb la sèrie 7.0: avui, a pve-no-subscription, el paquet és proxmox-kernel-7.0 en versió 7.0.14-12, i és el que arrossega proxmox-default-kernel. Proxmox VE 8 encara va amb proxmox-kernel-6.8.

Que la sèrie sigui la bona no ens garanteix que el build concret de Proxmox porti el suport, i això caldrà comprovar-ho quan surtin els paquets; ho diem perquè no ho hem verificat. El que sí que és segur és l'altra direcció, i és la que trenca coses: en un node amb kernel 6.8, una clau client. rotada a aes256k i feta servir per mapar un RBD deixa d'autenticar-se. Aquí l'ordre és primer el kernel, després la clau. I mentrestant, el silenciador de vuit setmanes.

Els dos d'RGW, i la trampa del multisite

El CVE-2026-54330 és senzill d'explicar: el verificador SigV4 d'RGW només comprovava les capçaleres llistades a X-Amz-SignedHeaders i ignorava la resta. Amb una URL prefirmada de PUT a la mà —d'aquelles que es reparteixen perquè algú pugi un fitxer— se li podien penjar capçaleres x-amz-* que qui va signar mai no va autoritzar. ACL incloses. El pedaç rebutja aquestes peticions.

El CVE-2026-39944 és el germà del de CephX: mateixa arrel, un altre lloc. Els tokens de sessió STS d'RGW es xifren amb el mateix AES-CBC sense autenticar, així que qui tingui un token vàlid pot invertir els camps acct_type i is_admin sense que ningú ho noti i sortir amb permisos d'administrador de la passarel·la. Només t'afecta si tens STS activat (rgw_s3_auth_use_sts = true), que és el normal si reparteixes credencials temporals a aplicacions.

I aquí arriba el detall que cal apuntar al tiquet: el client REST que fa servir el mateix multisite d'RGW generava peticions així. Ceph ho escriu sense adorns: «If you are running multisite, you must set the rgw_sigv4_insecure option to true before you begin to upgrade. After all clusters are upgraded, set the option to false again». És a dir, per poder aplicar el pedaç cal encendre un interruptor que deixa la fallada oberta, i recordar-se d'apagar-lo quan totes les zones estiguin al dia. Aquell «recordar-se» és el que es perd. Escriu-ho amb data i responsable.

Què faríem aquesta setmana

• Inventari abans que pedaç. ceph auth ls i comptar quantes credencials tenen mon allow r i de qui són. Aquest nombre és la mida real de la feina del pas 9.
• Mirar què hi ha al magatzem. ceph config-key ls. Si apareixen entrades de dm-crypt, ja saps quins secrets caldrà rotar i pots començar a planificar-ho, encara que el procediment formal no existeixi.
• Si és cephadm, rotar ja la clau SSH. No depèn del pedaç i és la que dona root a tots els nodes.
• Si és Proxmox, preparar la finestra. Amb deu passos manuals, un clúster de tres nodes no es fa en una tarda tranquil·la. I ja que s'atura cada OSD, és bon moment per revisar de passada què està rendint de debò cada disc.
• No estrenar Tentacle alhora. Si pensaves saltar de branca, separa-ho: primer es pedaça on ets. Ja vam escriure aquí sobre què porta Tentacle i què porta apagat, i cap d'aquestes novetats no mereix barrejar-se amb una rotació de claus.

L'avís demana actualitzar com abans millor i fa bé de demanar-ho. La lletra següent és la que canvia el calendari: tres de les quatre fallades se'n van amb el paquet, i la quarta se'n va el dia que hagis canviat l'última clau del clúster. El que hi ha entre aquestes dues dates és un projecte petit, amb la seva finestra, la seva marxa enrere i una clau d'emergència desada on no se t'esborri.

Fonts (verificades el 20 d'agost del 2026): el títol de l'avís, la data del 19 d'agost, la frase sobre la recomanació d'actualitzar, els passos crítics, l'automatització de cephadm i Rook, les sis comprovacions de salut noves i la instrucció sobre rgw_sigv4_insecure en multisite, de l'anunci de Squid 19.2.6 i Tentacle 20.2.4 signat per Patrick Donnelly. Les descripcions, el desglossament d'impacte, les versions afectades i corregides, els crèdits i les frases citades literalment, de les fitxes de CVE-2025-30156, CVE-2026-50152, CVE-2026-39944 i CVE-2026-54330 a la documentació de seguretat de Ceph. Els deu passos, les ordres, els advertiments i la frase sobre silenciar l'avís vuit setmanes, de la referència de configuració de CephX, secció «Upgrading and Rotating CephX Keys». Els noms de les sis comprovacions de salut i el fet que dues surtin amb [ERR], de la pàgina de health checks. La severitat High dels quatre, de l'índex de vulnerabilitats de Ceph. Són nostres les consultes als repositoris públics de Proxmox (ceph-squid i ceph-tentacle per a trixie i bookworm, i pve-no-subscription per als kernels), fetes avui a les 13:40 amb l'ordre que apareix al text; l'ordre és reproduïble i dona la mateixa resposta des de qualsevol lloc. És nostra també la lectura sobre l'abast de mon allow r en clients RBD i CephFS, declarada com a lectura al text. Les citacions de Ceph es deixen en anglès, el seu idioma original, perquè es puguin verificar paraula per paraula.