Ceph parchea cuatro CVE: tres los cierra el paquete y el cuarto lo cierras tú

Ayer miércoles el proyecto Ceph publicó dos versiones con un título que no se ve todos los años: «[CVE] [URGENT] Squid v19.2.6 and Tentacle v20.2.4 released». Cuatro CVE de una tacada. Y, en la sección de pasos críticos, una frase que le cambia la semana a mucha gente: CephX estrena tipo de clave. Es la primera vez que pasa.

La recomendación del proyecto es la de siempre y es la correcta: «We strongly recommend that all Ceph operators upgrade to one of these releases as soon as possible». Pero conviene leer lo que viene detrás, porque de los cuatro fallos, tres se van con el paquete y uno no. El cuarto se va cuando alguien haya rotado, una por una, todas las claves del clúster. Eso no cabe en una ventana de mantenimiento de media hora.

Los cuatro, en una tabla

Los cuatro figuran como High en el índice de vulnerabilidades del propio proyecto, y los cuatro empiezan igual en «versiones afectadas»: all prior versions. No hay rama vieja fuera de peligro. Conviene mirar debajo de esa etiqueta, porque el desglose CVSS de cada ficha no coincide: los cuatro son High en confidencialidad, pero sólo dos lo son también en integridad. Y los dos de RGW sólo te tocan si tienes pasarela S3.

Una clave de solo lectura y todo el llavero

El CVE-2026-50152 es el que más incomoda leer. La descripción de Ceph no deja margen a la interpretación: «Any CephX user holding mon allow r caps can read the entire Monitor config-key store by sending a single crafted MMonSubscribe message». Un mensaje. Sin condiciones adicionales.

Lo interesante es qué se guarda ahí dentro, y también lo dice la ficha: «This includes OSD LUKS passphrases and, on cephadm-managed clusters, the SSH private key cephadm uses to authenticate on every Ceph host». El desglose de impacto lo remata: «An attacker can exfiltrate the entire cluster secret store, including dm-crypt keys, dashboard secrets, and gateway credentials».

La lectura es nuestra, pero cuesta poco hacerla: mon allow r es el permiso mínimo con el que sale cualquier cliente. Cada nodo que monta un RBD lo tiene, y cada cliente de CephFS también. Si has cifrado los OSD en reposo —lo que se pide en cuanto hay datos sensibles encima— la passphrase que abre esos discos vivía en el mismo almacén que ese cliente podía leer de una tirada, así que el disco seguía cifrado y la llave estaba a la vista de medio clúster.

El paquete cierra la lectura. Lo que el paquete no puede hacer es cambiar los secretos que llevan ahí desde que montaste el clúster. Y aquí Ceph es honesto hasta el punto de resultar inquietante: «Formal guidance on rotating all secrets stored in the Monitor config-key store will be forthcoming». De momento sólo hay procedimiento establecido para uno de ellos, la clave SSH de cephadm. Para el resto, la recomendación literal es que cada operador «assess their cluster's potential exposure».

El de CephX repite un error de 2004

El CVE-2025-30156 es el gordo, y su diagnóstico se lee casi como una confesión: «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». El IV fijo hace que dos textos iguales cifren igual, lo cual ya es feo. La falta de autenticación es lo grave: se pueden voltear bits del texto cifrado, cambiar lo que hay debajo, y nada lo detecta.

Hay un camino largo, criptográficamente entretenido, en el que el atacante actúa como oráculo de cifrado creando identidades con nombres a medida para recolectar bloques. Y hay un camino corto, que es el que asusta: «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, tiene una prueba de concepto demostrada que llega a administrador del clúster.

El arreglo se llama aes256k: AES256-CTS-HMAC-SHA384-192, el esquema de RFC 8009 que usa Kerberos 5. Confusor aleatorio de 128 bits en cada operación, HMAC-SHA384 para detectar manipulación, y robo de texto cifrado para no necesitar relleno. La lista de créditos también merece una línea: lo notificó Erin Shepherd, de e43.eu, y después de forma independiente David Mohren y Mark Nelson, de CLYSO; y también lo notificó y validó David Korczynski, de Ada Logics, porque lo encontró Anthropic «using agents to study the security of open-source projects».

Por qué instalar no basta para éste

Porque las claves que ya existen siguen siendo de tipo aes. El binario nuevo entiende el tipo nuevo, pero no reescribe las credenciales que tienes: mantiene compatibilidad hacia atrás a propósito, para que el clúster no se caiga al actualizar. Lo que hace es empezar a quejarse, con seis comprobaciones de salud que la propia documentación te avisa de que van a aparecer: AUTH_INSECURE_KEYS_CREATABLE, AUTH_INSECURE_KEYS_ALLOWED, AUTH_INSECURE_SERVICE_KEY_TYPE, AUTH_INSECURE_SERVICE_TICKETS, AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE y AUTH_INSECURE_CLIENT_KEY_TYPE.

Dos de esas seis no son avisos, son errores. ceph health detail las saca con [ERR]: AUTH_INSECURE_SERVICE_TICKETS y AUTH_INSECURE_SERVICE_KEY_TYPE. Traducido a lo que ve tu monitorización: el clúster se queda en HEALTH_ERR desde que actualizas hasta que terminas de rotar, que pueden ser semanas. Conviene saberlo antes de que suene el teléfono a las tres de la mañana, y conviene decírselo a quien esté de guardia.

Diez pasos, y el orden importa

El procedimiento que Ceph ha añadido a la referencia de configuración de CephX tiene diez pasos numerados. Uno de ellos, el sexto, lo desaconseja la propia documentación para la mayoría de despliegues. Este es el resumen, con los comandos que importan:

1. Permitir el tipo nuevo. En clústeres actualizados lo hacen los monitores solos; se comprueba mirando el campo auth_allowed_ciphers en la salida de ceph mon dump, donde debe aparecer aes,aes256k.
2. Cambiar el tipo por defecto para claves nuevas: ceph mon set auth_preferred_cipher aes256k. Puedes saltártelo a propósito si aún hay aplicaciones cliente que no lo entienden.
3. Rotar las claves de todos los demonios: mon. primero, luego mgr, osd y mds, uno a uno, parando el demonio antes. Guarda el mon.keyring que sale del primer comando: si un monitor estaba fuera de quórum durante la rotación, no tendrá la clave nueva y habrá que metérsela a mano.
4. Comprobar que el aviso ha desaparecido: ceph health detail ya no debe listar AUTH_INSECURE_SERVICE_KEY_TYPE. Si sigue ahí, queda algún demonio sin rotar.
5. Subir el cifrado de los tickets rotativos: ceph mon set auth_service_cipher aes256k.
6. Borrar los tickets rotativos viejos con ceph auth wipe-rotating-service-keys. Aquí la documentación dice literalmente «This is not recommended for most deployments»: es mejor dejar que caduquen solos en unas horas.
7. Impedir que se creen claves inseguras nuevas: ceph config set mon 'mon auth allow insecure key' false.
8. Rotar client.admin. Antes, crear una clave de rescate (client.admin-backup) y comprobar que funciona. Si te equivocas aquí sin red, la recuperación es larga.
9. Rotar el resto de claves de cliente, y copiar cada una a cada máquina que la usa. ceph health detail te las lista por nombre.
10. Prohibir el tipo viejo: ceph mon set auth_allowed_ciphers aes256k. Y aquí el aviso más serio del documento: hazlo con una sola clave sin rotar y te quedas fuera del clúster, con rescate por «Emergency Allowed Ciphers».

Hay una válvula de escape reconocida en la propia documentación, y agradecemos que esté: si no puedes rotar todavía una clave de cliente concreta, se puede silenciar el aviso con ceph health mute AUTH_INSECURE_CLIENT_KEY_TYPE 8w. Ocho semanas. El texto que acompaña al comando dice «We expect this to be typical situation for some clusters», lo cual es una forma elegante de admitir que esto va a llevar meses en instalaciones grandes.

Fuimos a mirar el repositorio de Proxmox

Buena parte de los clústeres Ceph que vemos en España los instala Proxmox VE, desde los repositorios que mantiene Proxmox. Así que esta tarde, antes de escribir nada, fuimos a mirar qué hay publicado. El comando cabe en una línea:

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}'

La última versión que devuelve, hoy 20 de agosto a las 13:40, es 19.2.5-pve2. En la rama Tentacle, 20.2.2-pve1. En bookworm, para quien siga en Proxmox VE 8, 19.2.5-1~bpo12+2. Los índices no se han tocado desde el 27 de julio (Squid en trixie), el 29 de julio (Squid en bookworm) y el 7 de julio (Tentacle). Ninguna de las versiones parcheadas está ahí.

No es un reproche: empaquetar una release de Ceph con la seriedad con la que lo hace Proxmox lleva su tiempo, y el aviso tiene menos de veinticuatro horas. Es un dato que cambia el plan de esta semana, porque si tu Ceph lo instala Proxmox, hoy no hay nada que instalar y sí bastante que preparar. Y porque conviene tener el reflejo de mirar el repositorio en vez de fiarse de que un apt upgrade traiga lo que crees que trae — es el mismo reflejo que hace falta con las fechas de fin de soporte.

Hay una segunda consecuencia, y esta es la que pesa. La nota de Ceph dice que «deployments using cephadm will automate the process except for client keys». Proxmox gestiona los demonios de Ceph él mismo, sin cephadm. La automatización, que en cephadm cubre todo menos las claves de cliente, aquí no sirve: en un clúster hiperconvergido de Proxmox la rotación es a mano, entera, monitor por monitor y OSD por OSD.

El kernel, que aquí sí acompaña

El cliente Ceph del kernel —el que usan krbd y los montajes de CephFS— también tiene que entender aes256k, aunque Ceph matiza que las actualizaciones de cliente y kernel «are recommended to support the new key type but not required to resolve the most serious aspects of the security vulnerability». Sobre qué kernel hace falta es concreto: «Linux kernel support began in 7.0 and has been backported to CentOS Stream 9 and 10». Proxmox VE 9 va con la serie 7.0: hoy, en pve-no-subscription, el paquete es proxmox-kernel-7.0 en versión 7.0.14-12, y es del que tira proxmox-default-kernel. Proxmox VE 8 sigue en proxmox-kernel-6.8.

Que la serie sea la buena no nos garantiza que el build concreto de Proxmox lleve el soporte, y eso habrá que comprobarlo cuando salgan los paquetes; lo decimos porque no lo hemos verificado. Lo que sí es seguro es la otra dirección, y es la que rompe cosas: en un nodo con kernel 6.8, una clave client. rotada a aes256k y usada para mapear un RBD deja de autenticarse. Ahí el orden es primero el kernel, luego la clave. Y mientras tanto, el silenciador de ocho semanas.

Los dos de RGW, y la trampa de multisite

El CVE-2026-54330 es sencillo de contar: el verificador SigV4 de RGW sólo comprobaba las cabeceras listadas en X-Amz-SignedHeaders e ignoraba el resto. Con una URL prefirmada de PUT en la mano —de esas que se reparten para que alguien suba un fichero— se le podían colgar cabeceras x-amz-* que quien firmó nunca autorizó. ACL incluidas. El parche rechaza esas peticiones.

El CVE-2026-39944 es el hermano del de CephX: misma raíz, otro sitio. Los tokens de sesión STS de RGW se cifran con el mismo AES-CBC sin autenticar, así que quien tenga un token válido puede voltear los campos acct_type e is_admin sin que nadie lo note y salir con permisos de administrador de la pasarela. Sólo te afecta si tienes STS activado (rgw_s3_auth_use_sts = true), que es lo normal si repartes credenciales temporales a aplicaciones.

Y aquí llega el detalle que hay que apuntar en el ticket: el cliente REST que usa el propio multisite de RGW generaba peticiones así. Ceph lo escribe sin adornos: «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». O sea, para poder aplicar el parche hay que encender un interruptor que deja el fallo abierto, y acordarse de apagarlo cuando todas las zonas estén al día. Ese «acordarse» es lo que se pierde. Escríbelo con fecha y responsable.

Qué haríamos esta semana

• Inventario antes que parche. ceph auth ls y contar cuántas credenciales tienen mon allow r y de quién son. Ese número es el tamaño real del trabajo del paso 9.
• Mirar qué hay en el almacén. ceph config-key ls. Si aparecen entradas de dm-crypt, ya sabes qué secretos hay que planificar rotar, aunque el procedimiento formal aún no exista.
• Si es cephadm, rotar ya la clave SSH. No depende del parche y es la que da root en todos los nodos.
• Si es Proxmox, preparar la ventana. Con diez pasos manuales, un clúster de tres nodos no se hace en una tarde tranquila. Y ya que se para cada OSD, es un buen momento para revisar de paso qué está rindiendo de verdad cada disco.
• No estrenar Tentacle a la vez. Si estabas pensando en saltar de rama, sepáralo: primero se parchea donde estás. Ya escribimos aquí sobre lo que Tentacle trae y lo que trae apagado, y ninguna de esas novedades merece mezclarse con una rotación de claves.

El aviso pide actualizar cuanto antes y hace bien en pedirlo. La letra siguiente es la que cambia el calendario: tres de los cuatro fallos se van con el paquete, y el cuarto se va el día que hayas cambiado la última clave del clúster. Lo que hay entre esas dos fechas es un proyecto pequeño, con su ventana, su marcha atrás y una clave de emergencia guardada donde no se te borre.

Fuentes (verificadas el 20 de agosto de 2026): el título del aviso, la fecha del 19 de agosto, la frase sobre la recomendación de actualizar, los pasos críticos, la automatización de cephadm y Rook, las seis comprobaciones de salud nuevas y la instrucción sobre rgw_sigv4_insecure en multisite, del anuncio de Squid 19.2.6 y Tentacle 20.2.4 firmado por Patrick Donnelly. Las descripciones, el desglose de impacto, las versiones afectadas y corregidas, los créditos y las frases citadas literalmente, de las fichas de CVE-2025-30156, CVE-2026-50152, CVE-2026-39944 y CVE-2026-54330 en la documentación de seguridad de Ceph. Los diez pasos, los comandos, las advertencias y la frase sobre silenciar el aviso ocho semanas, de la referencia de configuración de CephX, sección «Upgrading and Rotating CephX Keys». Los nombres de las seis comprobaciones de salud y el hecho de que dos de ellas salgan con [ERR], de la página de health checks. La severidad High de los cuatro, del índice de vulnerabilidades de Ceph. Son nuestras las consultas a los repositorios públicos de Proxmox (ceph-squid y ceph-tentacle para trixie y bookworm, y pve-no-subscription para los kernels), hechas hoy a las 13:40 con el comando que aparece en el texto; el comando es reproducible y da la misma respuesta desde cualquier sitio. Es nuestra también la lectura sobre el alcance de mon allow r en clientes RBD y CephFS, declarada como lectura en el texto. Las citas de Ceph se dejan en inglés, su idioma original, para que se puedan verificar palabra por palabra.