Una escapada de VM sense CVE ni pedaç: què abasta root en un node de Proxmox

Hi ha un avís de fuga de convidat a amfitrió a KVM que no es pot pedaçar, perquè encara no existeix el pedaç ni el número que l'identifica. El que sí que es pot mesurar avui és fins on arribaria una fuga així en un clúster de Proxmox. Són menys passos dels que la gent compta.

El dimarts 6 d'octubre del 2026, The Register va explicar que l'investigador Paulos Yibelo va publicar a X «a screenshot of a bug bounty award he won for discovering what he described as "Full VM escape zeroday (guest>host root in industry standard hypervisors)!"», i que el conseller delegat de Vercel, Guillermo Rauch, va escriure: «We've confirmed a KVM 0day through our Vercel Sandbox bounty program». El mateix article explica per què això ens toca als qui vivim de la virtualització, i anomena la casa pel seu nom: «Enterprise virtualization players Nutanix, HPE, and Proxmox also rely on KVM».

El que se sap i el que no

A Proxmox, el salt és un

Quan es llegeix «guest>host root», el compte mental de molta gent són dos esglaons: primer surts del convidat i caus al procés de l'hipervisor, després escales a root a la màquina. A Proxmox VE aquest segon esglaó no existeix, i ho diu la seva pròpia documentació de QEMU/KVM:

QEMU inside Proxmox VE runs as a root process, since this
is required to access block and PCI devices.

La mateixa pàgina n'explica el motiu: «From the perspective of the host system where QEMU is running, QEMU is a user program which has access to a number of local resources like partitions, files, network cards». Un programa amb accés a disc i a PCI necessita root, i la decisió és defensable. El que canvia és l'aritmètica de la notícia: qui surti del convidat aterra directament amb l'usuari que mana al node, sense un replà intermedi on la teva telemetria el pugui veure ensopegar.

I la carpeta on arriba no és d'aquell node

Proxmox desa la seva configuració a pmxcfs, que la seva documentació defineix com «a database-driven file system for storing configuration files, replicated in real time to all cluster nodes using corosync». És la carpeta /etc/pve que veus a cada node, i és la mateixa a tots. A dins hi ha una subcarpeta amb permisos propis: «Files below the following paths are only accessible by root: /etc/pve/priv/» (i també /etc/pve/nodes/${NAME}/priv/). Justament l'usuari on acaba d'aterrar la fuga.

Les deu línies, tal com les llista la documentació

Això és el que aquella documentació enumera allà dins, amb la descripció que ella mateixa posa a cada fitxer. L'única cosa que hem tocat és expandir el prefix: la taula original els escriu com priv/authkey.key i aquí van amb la ruta sencera— i partir en dues línies les dues descripcions que no hi cabien de llargues.

/etc/pve/priv/authkey.key        Private key used by ticket system
/etc/pve/priv/authorized_keys   SSH keys of cluster members for authentication
/etc/pve/priv/ceph*             Ceph authentication keys and associated capabilities
/etc/pve/priv/known_hosts       SSH keys of the cluster members for verification
/etc/pve/priv/lock/*            Lock files used by various services to ensure
                                safe cluster-wide operations
/etc/pve/priv/pve-root-ca.key   Private key of cluster CA
/etc/pve/priv/shadow.cfg        Shadow password file for PVE Realm users
/etc/pve/priv/storage/<STORAGE-ID>.pw
                                Contains the password of a storage in plain text
/etc/pve/priv/tfa.cfg           Base64-encoded two-factor authentication configuration
/etc/pve/priv/token.cfg         API token secrets of all tokens

L'única de les deu que es rota sola

La primera línia té una particularitat que canvia com es llegeix la llista sencera, i per veure-la cal sortir de la documentació i anar al codi. authkey.key és la clau amb què el sistema de tiquets signa les sessions de la interfície i de l'API. Proxmox la rota sola: a PVE::AccessControl hi ha dues constants fixes, my $ticket_lifetime = 3600 * 2; # 2 hours i my $authkey_lifetime = 3600 * 24; # rotate every 24 hours, i una funció rotate_authkey() que es dispara sola quan la clau caduca. Dels deu fitxers d'aquella carpeta, nou són material de credencials i un, lock/*, són fitxers de bloqueig que no cal rotar. D'aquests nou, authkey.key és l'únic que no has de ficar en cap procediment: es renova sola cada 24 hores, amb cinc minuts de gràcia per a la clau anterior i tiquets que viuen dues hores, i la rotació es dispara quan el sistema torna a necessitar signar, no per rellotge. Les altres vuit continuen valent demà, i el mes vinent.

I cap d'aquests fitxers pertany al node on va caure el convidat. pmxcfs els replica en temps real a tots. Un node compromès és, per construcció, la carpeta de secrets del clúster sencer, tinguis tres nodes o dotze, i tant se val en quin fos la màquina virtual que va fallar. El que ens va costar un post sencer explicar en termes de el que costa root aliè en un hipervisor aquí es veu d'un cop d'ull, en una taula de la documentació que fa anys que és publicada.

La línia que més costa llegir dues vegades

És la vuitena: «Contains the password of a storage in plain text». Si el teu emmagatzematge de còpies és un Proxmox Backup Server, allà hi ha la credencial amb què el clúster hi parla. I la documentació d'emmagatzematge col·loca en aquesta mateixa carpeta dos veïns: la clau de xifratge, «saved in a file under /etc/pve/priv/storage/<STORAGE-ID>.enc», i la pública mestra, a .master.pem. La contrasenya de les còpies i la clau per desxifrar-les, el mateix directori i el mateix permís.

Què pot fer aquesta credencial quan algú se l'emporta ja ho vam explicar, i no ho reimprimirem: el repartiment de permisos d'esborrat i el token de còpia que no pot esborrar són a Proxmox Protected no és un cadenat, de l'agost, on a més dèiem que la retenció ha de viure al servidor de còpies i no al client; i la credencial de consola que abastava més del que deia el seu nom, ahir. El que allà no hi és, i és l'únic que hi afegim aquí, és el mode de fallada: si retalles el token però deixes la retenció configurada a l'emmagatzematge del clúster, la feina de còpia intentarà podar al final i acabarà en error de permisos aquella mateixa nit. Moure la retenció va abans que retallar el token, no després.

L'entregable: la llista de rotació, línia a línia

Si la carpeta és del clúster i no del node, aleshores el dia que un sol node es doni per compromès —per aquesta fuga, per una credencial filtrada o per un disc que se'n va anar a reparar sense esborrar— no es rota una contrasenya: es rota la llista sencera de dalt. Escriure aquesta llista costa una tarda en fred i un cap de setmana en calent. Cada línia té el seu propi cost i convé estimar-lo abans:

La fallada és inevitable, l'avaria és una decisió de disseny. Que un hipervisor tingui alguna vegada una fuga de convidat a amfitrió no ho decideixes tu: els ha tingut tots. El que decideixes és quant trigues a saber què cal canviar quan passi, i això s'escriu avui, sense pedaç i sense CVE, mirant una taula de deu línies.

El que no afirmem

Amb un clúster petit i la consola a mà, la llista de rotació l'escriu la teva gent en una tarda. Es complica quan ningú recorda quins tokens d'API hi ha vius, quan el servidor de còpies el va muntar algú que ja no hi és, o quan la xarxa de gestió comparteix VLAN amb les màquines dels usuaris perquè així va arrencar el projecte. Decidir què abasta cada credencial i cada segment, i deixar-ho escrit, és feina de zero trust; cronometrar la recuperació comptant el que aquesta rotació costa és feina de disaster recovery. Venem tots dos, així que llegeix-ho amb el conflicte d'interès al davant. Si la teva gent ja té la llista escrita, tanca aquesta pestanya. Si en llegir la taula de deu línies has pensat «d'aquesta no sabria ni per on començar», parlem-ne.

Fonts