Canonical ha rilasciato correzioni per un difetto nel controllo dei certificati che permette agli attaccanti di impersonare client attendibili di LXD e MicroCloud senza disporre delle loro chiavi private, riferisce The Hacker News. L'avviso di sicurezza di Ubuntu del 30 ottobre identifica la vulnerabilità di LXD come CVE-2026-112816, che può concedere a un attaccante non autenticato pieno accesso a un cluster e alle macchine virtuali gestite.
Lo sfruttamento richiede l'accesso di rete all'API HTTPS, cioè l'interfaccia cifrata usata per gestire il servizio, e il certificato pubblico di un'identità considerata attendibile dal server. L'attaccante ottiene l'accesso di quell'identità; impersonare un account privilegiato potrebbe anche fornire l'accesso root alla macchina host, ha dichiarato Canonical in dichiarazioni riportate da The Hacker News.
Le installazioni autonome di LXD non espongono di default questa interfaccia di rete. Restano in ascolto su un socket locale, a meno che un amministratore non abiliti l'accesso di rete tramite core.https_address. MicroCloud, che unisce macchine con LXD in un cluster, presenta un'esposizione particolare: Canonical ha dichiarato che un attaccante che cattura il certificato pubblico di un membro mentre questo entra nel cluster può successivamente impersonarlo.
La vulnerabilità ha un punteggio massimo di 10,0 nel Common Vulnerability Scoring System, mentre Ubuntu le assegna una priorità di correzione separata, pari a Media. The Hacker News riferisce che la valutazione CISA del 30 ottobre, riportata nel record CVE, descriveva lo sfruttamento come non noto: la falla non era presente nel catalogo Known Exploited Vulnerabilities di CISA e non era stato pubblicato alcun exploit funzionante.
Come un certificato pubblico diventa un accesso
LXD e MicroCloud supportano il mutual TLS, una configurazione della connessione in cui i client presentano certificati per stabilire la propria identità. I server conservano le identità accettate in un trust store. Un certificato pubblico non è segreto; la chiave privata corrispondente dovrebbe dimostrare che il client è titolare dell'identità.
La falla annulla questa distinzione. Durante la configurazione della connessione, il TLS dimostra il possesso della chiave privata solo per il primo certificato presentato, detto certificato foglia (leaf certificate). I controlli di autenticazione vulnerabili confrontavano comunque ogni certificato della catena del client con il trust store, compresi i certificati aggiuntivi che il client poteva allegare liberamente.
Un attaccante potrebbe quindi presentare per primo il proprio certificato e aggiungere il certificato pubblico di un client attendibile. Il server accetterebbe l'identità attendibile anche se l'attaccante non possedesse la relativa chiave privata.
Il progetto Incus, un fork di LXD nato dalla comunità, ha segnalato il problema, e Canonical ha confermato che anche LXD era interessato, ha riferito The Hacker News. Incus ha pubblicato il proprio avviso di sicurezza il 29 ottobre, un giorno prima dell'avviso di Ubuntu. Lo stesso avviso indica che il comportamento è presente dalla prima versione di Incus e interessa le versioni precedenti alla 7.6.0.
Incus descrive ulteriori vie di accesso
L'avviso di Incus descrive conseguenze all'interno del prodotto che vanno oltre l'impersonazione di un normale client. Chiunque riesca a raggiungere il suo listener HTTPS può impersonare un client attendibile, un'identità per le metriche o un certificato di server di cui possiede il certificato pubblico. L'impersonazione di un membro del cluster aggira interamente l'autorizzazione.
Ottenere un certificato pubblico adatto potrebbe non richiedere alcun accesso preventivo a Incus: i server restituiscono i propri certificati durante ogni handshake TLS. Aggiungere il certificato del server bersaglio consente l'accesso al gateway del database; aggiungere il certificato di un altro membro del cluster concede l'accesso interno al cluster. I client attendibili possono inoltre recuperare i certificati dei client tramite l'API dei certificati, e i certificati possono essere ottenuti dai server che tali client hanno contattato.
Incus afferma che la falla consente anche il rinnovo o la cancellazione di qualsiasi voce del trust store tramite percorsi self-service e interessa l'autenticazione della connessione dell'agente tra host e macchine virtuali.
Una conseguenza ulteriore riguarda lo scriptlet di autorizzazione, uno script usato per prendere decisioni di accesso. Incus passava la catena di certificati non verificata a quello script, permettendo a certificati scelti dall'attaccante di influenzarne le decisioni. Questo riguarda anche i client che si autenticano tramite token o OpenID Connect, un metodo di accesso basato sull'identità, perché possono comunque presentare certificati arbitrari durante la configurazione del TLS.
Questi impatti dettagliati sono le conclusioni dell'avviso di Incus. Quest'ultimo tiene traccia del problema come GHSA-xg75-xf37-cph9 e non elenca alcun identificativo CVE noto.
Versioni corrette e azioni per gli amministratori
L'avviso di Ubuntu elenca come interessate le versioni LXD 4.0.14, 5.0.10, 5.21.8 e 6.9, prima delle rispettive versioni corrette. The Hacker News riporta queste versioni corrette degli snap, raggruppate per prodotto e canale:
- LXD
6/stable: 6.10.1. - LXD
5.21/stable: 5.21.9. - LXD
5.0/stable: 5.0.11. - LXD
4.0/stable: 4.0.15. - MicroCloud
3/stable: 3.4.1. - MicroCloud
2/stable: 2.1.5.
Lo stato dei pacchetti nell'archivio di Ubuntu è separato da queste installazioni snap. I pacchetti LXD per Ubuntu 20.04, 18.04 e 16.04 sono contrassegnati come non interessati; per le release 22.04, 24.04, 26.04 e 26.10, LXD risulta non presente.
Gli amministratori che usano gli snap dovrebbero aggiornare i prodotti installati con sudo snap refresh lxd e sudo snap refresh microcloud. Canonical ha dichiarato che, quando è stato pubblicato il suo avviso, le versioni correttive di LXD stavano ancora passando dal canale candidate allo stable; per questo gli amministratori dovrebbero verificare la versione installata dopo l'aggiornamento.
The Hacker News riferisce che l'avviso di Canonical non prevede alcuna soluzione temporanea per LXD. Limitare l'accesso di rete all'API HTTPS riduce l'esposizione mentre gli aggiornamenti vengono applicati. Incus raccomanda esplicitamente di limitare il proprio listener HTTPS agli host attendibili e afferma che non esiste una soluzione basata sulla configurazione. Gli amministratori di Incus dovrebbero aggiornare alla versione 7.6.0, che corregge questa falla insieme ad altri diciassette problemi di sicurezza.
