La certificate flaw di LXD consente l’impersonation di un trusted client
Una certificate flaw critica di LXD consente a un aggressore di impersonare un trusted client senza possedere la private key di quel client, il segreto usato per dimostrarne l’identità. Il problema riguarda i prodotti LXD e MicroCloud di Canonical e potrebbe esporre un cluster e le relative virtual machines, computer basati su software eseguiti all’interno di un host fisico. Canonical ha avvertito che impersonare un account con privilegi potrebbe fornire all’aggressore root access, ossia il pieno controllo amministrativo della macchina host.
La vulnerabilità è registrata come CVE-2026-112816 e ha il punteggio CVSS massimo di 10,0. CVSS, o Common Vulnerability Scoring System, è una scala standard per valutare la gravità delle vulnerabilità di sicurezza. Canonical ha rilasciato versioni corrette di LXD e MicroCloud, anche se gli amministratori devono verificare che la versione installata abbia effettivamente ricevuto l’aggiornamento.
LXD e MicroCloud consentono ai client remoti di connettersi tramite una HTTPS API, un’interfaccia di rete cifrata utilizzata dal software per scambiare istruzioni e dati. L’autenticazione viene gestita tramite mutual TLS, una connessione nella quale sia il server sia il client che si connette usano digital certificate per stabilire le rispettive identità. Un server considera attendibile un client quando il certificate di quel client compare nel suo trust store, l’elenco delle identità che è stato configurato per accettare.
La vulnerabilità riguardava il modo in cui il server esaminava la certificate chain inviata durante una connessione. Il server confrontava ogni certificate fornito dal client con le voci del proprio trust store. Tuttavia, la connessione TLS dimostra soltanto che il client che si connette possiede la private key appartenente al primo certificate della chain, noto come leaf certificate. Gli eventuali certificate aggiuntivi allegati dopo di esso vengono scelti dal client che si connette e non sono coperti da tale prova di possesso.
Un aggressore poteva quindi connettersi usando un certificate e una private key sotto il proprio controllo, per poi aggiungere il public certificate di un trusted client legittimo. I public certificate non sono segreti. Poiché il server vulnerabile controllava tutti i certificate nella chain inviata, poteva trovare il certificate attendibile e accettare l’aggressore come se fosse quel client, anche se l’aggressore non possedeva la private key del trusted client.
Lo sfruttamento richiede due condizioni. L’aggressore deve poter raggiungere tramite la rete la HTTPS API del bersaglio e deve disporre del public certificate di un client già considerato attendibile dal server. Un’installazione LXD autonoma non espone la propria API alla rete per impostazione predefinita. Rimane in ascolto soltanto tramite un socket locale, una connessione disponibile sulla stessa macchina, a meno che un amministratore non abiliti l’accesso di rete con l’impostazione core.https_address.
MicroCloud presenta un’ulteriore esposizione perché combina più macchine LXD in un cluster. Canonical ha dichiarato che un aggressore che acquisisce il public certificate di un membro mentre tale macchina entra nel cluster potrebbe successivamente autenticarsi come quel membro. Un’impersonation riuscita fornirebbe all’aggressore tutte le autorizzazioni relative al cluster e alle virtual machines assegnate a quell’identità.
Il record CVE identifica LXD 4.0.14, 5.0.10, 5.21.8 e 6.9 come versioni interessate prima dei rispettivi rilasci corretti. Canonical indica come corrette LXD 6.10.1 nel canale snap 6/stable, 5.21.9 in 5.21/stable, 5.0.11 in 5.0/stable e 4.0.15 in 4.0/stable. Per MicroCloud, le versioni corrette sono 3.4.1 in 3/stable e 2.1.5 in 2/stable. Uno snap è il formato applicativo pacchettizzato tramite il quale vengono distribuiti questi rilasci.
Il progetto Incus, nato come fork comunitario di LXD, ha segnalato per primo il problema sottostante. Canonical ha successivamente confermato che anche LXD era vulnerabile. Incus ha corretto la stessa vulnerabilità nella versione 7.6.0, insieme ad altri 17 problemi di sicurezza. I pacchetti LXD presenti nell’archivio di Ubuntu sono indicati come non interessati o non distribuiti; pertanto, i relativi rilasci LXD corretti sono i pacchetti snap.
Non vi sono indicazioni pubbliche secondo cui CVE-2026-112816 sia stata sfruttata. Una valutazione della U.S. Cybersecurity and Infrastructure Security Agency datata 30 ottobre afferma che non risulta che la vulnerabilità sia stata utilizzata in attacchi. Non è inclusa nell’elenco Known Exploited Vulnerabilities dell’agenzia e non è stato pubblicato alcun exploit funzionante.
Gli amministratori dovrebbero aggiornare le installazioni snap eseguendo sudo snap refresh lxd e sudo snap refresh microcloud. Al momento dell’avviso di Canonical, i point release corretti di LXD erano ancora in fase di passaggio dal canale candidate a stable. Dopo il refresh, gli amministratori dovrebbero quindi controllare la versione installata, anziché presumere che sia stato distribuito il rilascio corretto.
Canonical non ha fornito alcun workaround temporaneo per LXD. Limitare chi può raggiungere la HTTPS API può ridurre l’esposizione in attesa dell’aggiornamento, ma non corregge l’errore di convalida dei certificate. Anche il progetto Incus ha dichiarato che non esiste una soluzione basata sulla configurazione e ha consigliato di limitare l’accesso di rete al listener finché non sarà possibile aggiornare i sistemi. Gli utenti Incus devono installare la versione 7.6.0.
Le organizzazioni che necessitano di assistenza per proteggere l’ambiente IT circostante possono rivolgersi ad AEU-I per servizi IT, infrastrutture e consulenza orientati innanzitutto alla sicurezza. Per i deployment interessati, la priorità rimane installare il rilascio corretto, verificarne la versione e mantenere la management API inaccessibile dalle reti non attendibili.